I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
where many people are surprised why PHP can't have this done. Why
inconsistency is something that we want to keep because of backward
compatibility. PHP already introduced many backward compatibility
issues and this change could just be fixed in old PHP projects (prior
to for example PHP 6 or PHP 5.5) by just simple "find & replace"
script in really most of the cases. Why it is so hard to deprecate
functions that uses naming convention that dosen't really exist, that
names were created by some crazy "let's imagine some name and don't
look at API we have" man? Why we can't have PHP 6 that will be not
some amazingly featured-packed version but version with API that
just... makes sense.
Regards,
Damian Tylczyński
Hello,
you are right Damian.
Also today on a german page:
http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html
Relating to this bug report:
https://bugs.php.net/bug.php?id=52424
Best regards
Martin
hi,
On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis
martin.keckeis1@gmail.com wrote:
Hello,
you are right Damian.
Also today on a german page:
http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.htmlRelating to this bug report:
https://bugs.php.net/bug.php?id=52424
We all know that, since years. The answer however remains the same: We
can't do it without major backward compatibility breakages. Please
check the internals archive for the past discussions.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
2013/1/25 Pierre Joye pierre.php@gmail.com
hi,
On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis
martin.keckeis1@gmail.com wrote:Hello,
you are right Damian.
Also today on a german page:
Relating to this bug report:
https://bugs.php.net/bug.php?id=52424We all know that, since years. The answer however remains the same: We
can't do it without major backward compatibility breakages. Please
check the internals archive for the past discussions.
Theoretically you can have both: The API in it's current state as well as a
consistent api in the "php"-namespace.
Cheers,
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
--
Hi!
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
where many people are surprised why PHP can't have this done. Why
inconsistency is something that we want to keep because of backward
compatibility. PHP already introduced many backward compatibility
I don't think you can just hand-wave the issue away by saying "PHP
introduced BC breaks". First, PHP practically never introduced BC breaks
that breaks almost all existing code. Even when we did huge changes -
like OO model change - we had compatibility mode for a long time, and
that considering in most scenarios it still worked the same. BC breaks
happened, but they mattered only in some specific scenarios and usually
this was done because old way of doing it could no longer be practically
used or lead to bigger problems than BC (such as security issues or
frequent hard-to-find bugs).
Second, here we have breakage that would happen just for the sake of
satisfying some people that thing having or not having underscore in
function name really matters. For 99% of people out there, it does not.
I agree it'd be nice if we came back in time and wrote function naming
standard before PHP functions were implemented. But since we can't go
back in time, we have to choose between things that matter to most of
people - e.g., compatibility and code that keeps working when upgrading
to next PHP version - against naming beauty that doesn't matter for most
of them. I agree that beautiful is better than ugly. But, ugly but
working is better than beautiful but broken.
names were created by some crazy "let's imagine some name and don't
look at API we have" man? Why we can't have PHP 6 that will be not
some amazingly featured-packed version but version with API that
just... makes sense.
Because there would be zero incentive to upgrade to it for any current
user. You'd have to rewrite and retest your code with zero benefit. And
you'd have to maintain two codebases from now on for any application
that is supposed to run on both, or resort to all kinds of trickery to
keep it working. As someone working with 600K+ LOC code base, I don't
see doing that as something I'm eagerly waiting for. Then the question
is - why would we release a version that 99% of existing users would
hate to use?
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:
Hi!
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
where many people are surprised why PHP can't have this done. Why
inconsistency is something that we want to keep because of backward
compatibility. PHP already introduced many backward compatibilityI don't think you can just hand-wave the issue away by saying "PHP
introduced BC breaks". First, PHP practically never introduced BC breaks
that breaks almost all existing code. Even when we did huge changes -
like OO model change - we had compatibility mode for a long time, and
that considering in most scenarios it still worked the same. BC breaks
happened, but they mattered only in some specific scenarios and usually
this was done because old way of doing it could no longer be practically
used or lead to bigger problems than BC (such as security issues or
frequent hard-to-find bugs).Second, here we have breakage that would happen just for the sake of
satisfying some people that thing having or not having underscore in
function name really matters. For 99% of people out there, it does not.
I agree it'd be nice if we came back in time and wrote function naming
standard before PHP functions were implemented. But since we can't go
back in time, we have to choose between things that matter to most of
people - e.g., compatibility and code that keeps working when upgrading
to next PHP version - against naming beauty that doesn't matter for most
of them. I agree that beautiful is better than ugly. But, ugly but
working is better than beautiful but broken.names were created by some crazy "let's imagine some name and don't
look at API we have" man? Why we can't have PHP 6 that will be not
some amazingly featured-packed version but version with API that
just... makes sense.Because there would be zero incentive to upgrade to it for any current
user. You'd have to rewrite and retest your code with zero benefit. And
you'd have to maintain two codebases from now on for any application
that is supposed to run on both, or resort to all kinds of trickery to
keep it working. As someone working with 600K+ LOC code base, I don't
see doing that as something I'm eagerly waiting for. Then the question
is - why would we release a version that 99% of existing users would
hate to use?Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Throwing warnings on perfectly working code is really a bad idea. It
annoys users, slows down their code, and doesn't add any value at all to
them.
It should also be noted that many of the function names that people
don't think are consistent are actually quite consistent when you
consider that PHP is just a thin wrapper on top of underlying libraries.
Functions from libc like tempnam() and strlen() are perfectly fine. The
fact that you can go to your Linux command line and type: "man tempnam"
to get a good idea of what is happening behind the scenes of the PHP
function of the same name is a good thing.
-Rasmus
Yes, it's extremely useful, especially because most of the php developers
are developing under Linux and most of them are coming from C and many
other languages. Give ma a break... Second thing, we're afraid of throwing
deprecated errors. Let's see the case. On production machines there are
errors hidden from the users (display errors: none or just strict, notice,
deprecated types hidden), experienced developers when they will not like
them during development will disable them or migrate their code, new
developers will just learn new API. Where is the problem? I'm not talking
about removing some functions but just deprecating them to to get some time
and simply to be ready to improve the PHP as a language in the future when
time will come.
25 sty 2013 20:04, "Rasmus Lerdorf" rasmus@lerdorf.com napisał(a):
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?Throwing warnings on perfectly working code is really a bad idea. It
annoys users, slows down their code, and doesn't add any value at all to
them.It should also be noted that many of the function names that people
don't think are consistent are actually quite consistent when you
consider that PHP is just a thin wrapper on top of underlying libraries.
Functions from libc liketempnam()andstrlen()are perfectly fine. The
fact that you can go to your Linux command line and type: "man tempnam"
to get a good idea of what is happening behind the scenes of the PHP
function of the same name is a good thing.-Rasmus
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?Throwing warnings on perfectly working code is really a bad idea.
It could be a new type of notice then, which could be controlled by
configuration.
It annoys users,
The configuration could be turned off by default.
slows down their code,
Isn't it a flaw of the current implementation of throwing messages, which
could be improved? AFAIU, if suppressed warnings would not be processed as
the active ones, the performance effect would be negligible to zero.
and doesn't add any value at all to them.
It would add the value to those who care.
It should also be noted that many of the function names that people
don't think are consistent are actually quite consistent when you
consider that PHP is just a thin wrapper on top of underlying libraries.
Functions from libc liketempnam()andstrlen()are perfectly fine. The
fact that you can go to your Linux command line and type: "man tempnam"
to get a good idea of what is happening behind the scenes of the PHP
function of the same name is a good thing.
True.
Don't get me wrong, I personally don't mind using the good old names, even
typos in the names have their own charm. I just think that the point of
view of order-freaks could be respected a little after all these years of
complaints, so I'm trying to find a compromise and more PHP users would be
happy. :)
-Rasmus
Here I am, ten years later, and the same issue is being rehashed just as it
was when it was brought up ten years ago.
Over those ten years, things have slowly gotten better, but the underlying
issue remains the same. PHP is glue. PHP has not taken the path of
re-naming everything to conform to a new "PHP standard", other than
underscores, and attempts at function prefixes.
Sure, we could start adding aliases like libc_strlen(), and maybe that's
worth a thought, but its adding another layer of complexity, to achieve
simplicity.
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?Throwing warnings on perfectly working code is really a bad idea. It
annoys users, slows down their code, and doesn't add any value at all to
them.It should also be noted that many of the function names that people
don't think are consistent are actually quite consistent when you
consider that PHP is just a thin wrapper on top of underlying libraries.
Functions from libc liketempnam()andstrlen()are perfectly fine. The
fact that you can go to your Linux command line and type: "man tempnam"
to get a good idea of what is happening behind the scenes of the PHP
function of the same name is a good thing.-Rasmus
Hi!
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Well, the problem with these things is this: suppose you have testing
suite that verifies your code. What you do with E_DEPRECATED? You can
treat them as failure, and that means in hypothetical PHP 6 release you
code is broken, and you can't release it until you fixed it - so that
means for you the effect it as if the function was effectively removed.
On the other hand, you can ignore it - and then when these functions are
removed, you get all your code broken, and while it is not removed, it's
like we didn't do anything.
The purpose of deprecation is to give you time to upgrade your code, but
the question here is - why would you want to change your perfectly
working code, if there would be no benefit to you but couple of
underscored placed here and there so people could feel better knowing
every function has underscore in the same place? As I said, while it's
nice, I don't think it is worth it. When the change is necessary - e.g.,
when we have API that is flawed or unsafe, take the recent example of
CURL file uploading API, which exposes tricky security issues - then
deprecation/removal may be warranted, because your code, that you think
is working, might in fact have security hole. So we find that avoiding
security hole is more important. But I personally do not see how adding
underscores is as important.
If somebody came forward and proposed better API - that could exist in
parallel with current one, but eventually replace it if people like it
so much nobody would use the old one anymore - it could be discussed.
But just shuffling couple of underscores here and there - really, I
don't see how it is worth the trouble.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATEDorE_STRICTon their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
Well, the problem with these things is this: suppose you have testing
suite that verifies your code. What you do with E_DEPRECATED? You can
treat them as failure, and that means in hypothetical PHP 6 release you
code is broken, and you can't release it until you fixed it - so that
means for you the effect it as if the function was effectively removed.
On the other hand, you can ignore it - and then when these functions are
removed, you get all your code broken, and while it is not removed, it's
like we didn't do anything.
Depending on just what is going to change, a simple script people can
run to scan their code and spit out a diff of recommended changes they
can simply review and approve of could be pretty painless.
Then again you probably have people that would be subject to vendor
updates without the ability to run the script or understand the changes
it recommends. May be a small minority though.
Are we talking mostly needle/haystack & haystack/needle type BC changes
here or other more nefarious things?
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
Would be a bit more in the core, for a time, but would allow people to
transition when they wanted to, without all of the errors...
--
-Clint
Hi!
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration parameter" is a solution to
almost any BC problem in the engine. It's not true, actually it's the
opposite - now you have to maintain two code bases, one for one value of
the parameter and one for another. Now imagine there's 10 such
parameters, for different things in PHP, and you get 1024 options to
test you application on. That's why we try to reduce behavior-modifying
options to a minimum. Config options are for configuration, not for
changing engine behavior in BC-breaking way. That's one of the reasons
why magic_* were not a good idea and we had to get rid of them.
And imagine integrating a library that is written with one set of engine
options into application that expects another set of options. Now
imagine application that uses a dozen of third-party libraries (in
current open-source world, it's not too many at all), each of them
expecting its own set of engine-modifying options. It would very quickly
become a complete nightmare.
So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?
People think that "introduce a configuration parameter" is a solution to
almost any BC problem in the engine. It's not true, actually it's the
opposite - now you have to maintain two code bases, one for one value of
the parameter and one for another. Now imagine there's 10 such
parameters, for different things in PHP, and you get 1024 options to
test you application on. That's why we try to reduce behavior-modifying
options to a minimum. Config options are for configuration, not for
changing engine behavior in BC-breaking way. That's one of the reasons
why magic_* were not a good idea and we had to get rid of them.And imagine integrating a library that is written with one set of engine
options into application that expects another set of options. Now
imagine application that uses a dozen of third-party libraries (in
current open-source world, it's not too many at all), each of them
expecting its own set of engine-modifying options. It would very quickly
become a complete nightmare.So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.
I agree all of that would suck, but would it suck less than the
alternatives for the most people involved?
--
-Clint
Clint Priest wrote:
So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.
I agree all of that would suck, but would it suck less than the alternatives for
the most people involved?
E_STRICT is bad enough and is one of the switches you would have to test
everything against. But the main problem is that there is nothing in the
historic code base that easily allows someone to identify which version of PHP
IS required to run it? THIS is where move code forward to comply with the
existing 'E_DEPRECATED/E_STRICT' is a minefield, so adding yet another major
rework seems to be a step too far?
Now if someone could come up with a third party tool that reads an application
... identifies all of the problems ... and at least offer pointers to fix them ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Now if someone could come up with a third party tool that reads an
application ... identifies all of the problems ... and at least offer
pointers to fix them ...
I like that idea! Kinda surprised something like that doesn't already
exist, actually....
--Kris
Hi!
I agree all of that would suck, but would it suck less than the
alternatives for the most people involved?
Definitely not. I don't think most people involved care if it's called
htmlentities or html_entities. Those are things that you learn once and
don't care about them anymore, and if you forget, it takes a second to
open the manual or activate code completion in your IDE. Dragging people
into a language fragmentation and world of pain that follows just for
that definitely does not fit my definition of "suck less". I understand
there are some vocal people all over reddit and such that jump on every
mention of PHP and start complaining about how function naming sucks and
PHP is useless because of that. I think however the history proves it is
of rather little importance. If we could fix it without causing major
disruption - yeah, why not. But the cost of the solution you propose is
way too high.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
- What about using a new open tag?
<?php
if (strpos("hello", "lo")) {...
if (in_array(1, [1,2,3])) {...
<?php6
if (str_pos("hello", "lo")) {...
if (in_array([1,2,3], 1)) {...
if (strpos("hello", "lo")) {... // fatal error
$a = [1,2,3]; // ok
$a = array(1,2,3); // fatal error
Those who want to switch their code to the php6 standard can do it,
those who want to keep their code as it is are also happy.
Those who want to switch only some files in their code are also fine.
- Another option would be adding String and Array classes (similar to
DateTime):
<?php
String::setDefaultEncoding("UTF-8");
if (String::pos("hello", "lo")) {...
if (Array::contains([1,2,3], 1)) {...
or:
$s = new String("hello", "UTF-8");
if ($s->pos("lo")) {...
echo $s->htmlSpecialChars();
echo $s->convert("ISO-8859-1");
$a = new Array([1,2,3]);
if ($a->contains(1)) {...
Regards,
Thomas
Hi!
Realistically couldn't we just introduce a configuration parameter to
keep "the inconsistent parameter order," perhaps along with a script to
suggest the changes needed to bring some code up to speed?People think that "introduce a configuration parameter" is a solution to
almost any BC problem in the engine. It's not true, actually it's the
opposite - now you have to maintain two code bases, one for one value of
the parameter and one for another. Now imagine there's 10 such
parameters, for different things in PHP, and you get 1024 options to
test you application on. That's why we try to reduce behavior-modifying
options to a minimum. Config options are for configuration, not for
changing engine behavior in BC-breaking way. That's one of the reasons
why magic_* were not a good idea and we had to get rid of them.And imagine integrating a library that is written with one set of engine
options into application that expects another set of options. Now
imagine application that uses a dozen of third-party libraries (in
current open-source world, it's not too many at all), each of them
expecting its own set of engine-modifying options. It would very quickly
become a complete nightmare.So I think we should try to keep PHP behavior unified and avoid
behavior-modifying switches as much as possible.Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Please stop with these. We can't keep explaining why function aliases,
<?php6 and deprecating function names that have been in use for nearly
20 years is a bad idea.
There is a reason that REFERER is still around in HTTP. It is obviously
not spelled correctly, but the pain of fixing it would far outweigh the
appeasement of the pedants out there. Does it make it harder to figure
out HTTP-related stuff? Not really, you won't necessarily know this term
even exists until you learn about it. Same goes for PHP functions. If
you understand where they come from you expect them to be named strlen,
strchr, strpos, etc. and if you don't understand their origin then you
simply learn them or let your IDE autocomplete them for you.
And if you really think this is something a majority of people are
interested in, write up an RFC and put it to a vote. And when that fails
write yourself a userspace "consistency" library that names all the
functions the way you feel would make them consistent and put it out
there. or heck, if you are worried about performance of a userspace
wrapper, write an extension that does it. But please stop posting about
it on internals. There are a lot of real issues we should be spending
cycles on.
-Rasmus
Please stop with these. We can't keep explaining why function aliases,
<?php6 and deprecating function names that have been in use for nearly
20 years is a bad idea.There is a reason that REFERER is still around in HTTP. It is obviously
not spelled correctly, but the pain of fixing it would far outweigh the
appeasement of the pedants out there. Does it make it harder to figure
out HTTP-related stuff? Not really, you won't necessarily know this term
even exists until you learn about it. Same goes for PHP functions. If
you understand where they come from you expect them to be named strlen,
strchr, strpos, etc. and if you don't understand their origin then you
simply learn them or let your IDE autocomplete them for you.And if you really think this is something a majority of people are
interested in, write up an RFC and put it to a vote. And when that fails
write yourself a userspace "consistency" library that names all the
functions the way you feel would make them consistent and put it out
there. or heck, if you are worried about performance of a userspace
wrapper, write an extension that does it. But please stop posting about
it on internals. There are a lot of real issues we should be spending
cycles on.
I don't think this could have been phrased any better :)
tip of the hat
-Rasmus
So function aliases, new open tag and deprecation are bad. What about
the String class?
I think there was some "Let's ... start exploring lighter and more
approachable ways to attack Unicode" on internals ...
Regards,
Thomas
Please stop with these. We can't keep explaining why function aliases,
<?php6 and deprecating function names that have been in use for nearly
20 years is a bad idea.There is a reason that REFERER is still around in HTTP. It is obviously
not spelled correctly, but the pain of fixing it would far outweigh the
appeasement of the pedants out there. Does it make it harder to figure
out HTTP-related stuff? Not really, you won't necessarily know this term
even exists until you learn about it. Same goes for PHP functions. If
you understand where they come from you expect them to be named strlen,
strchr, strpos, etc. and if you don't understand their origin then you
simply learn them or let your IDE autocomplete them for you.And if you really think this is something a majority of people are
interested in, write up an RFC and put it to a vote. And when that fails
write yourself a userspace "consistency" library that names all the
functions the way you feel would make them consistent and put it out
there. or heck, if you are worried about performance of a userspace
wrapper, write an extension that does it. But please stop posting about
it on internals. There are a lot of real issues we should be spending
cycles on.-Rasmus
hi,
So function aliases, new open tag and deprecation are bad. What about
the String class?
I think there was some "Let's ... start exploring lighter and more
approachable ways to attack Unicode" on internals ...
Unicode is a totally different topic. I would suggest to look at intl
(ICU) extension for a start.
Also about cleanup the APIs, take a look at this prototype:
https://github.com/nikic/scalar_objects
This is something that would be much cleaner and without BC problems.
Cheers,
Pierre
@pierrejoye
I really like the idea
2013/1/26 Pierre Joye pierre.php@gmail.com:
hi,
So function aliases, new open tag and deprecation are bad. What about
the String class?
I think there was some "Let's ... start exploring lighter and more
approachable ways to attack Unicode" on internals ...Unicode is a totally different topic. I would suggest to look at intl
(ICU) extension for a start.Also about cleanup the APIs, take a look at this prototype:
https://github.com/nikic/scalar_objects
This is something that would be much cleaner and without BC problems.
Cheers,
Pierre
@pierrejoye
I think register_primitive_type_handler() is too exclusive:
When I use 2 frameworks in the same code base, one might do
register_primitive_type_handler('string', 'A\StringHandler') and the
other might do register_primitive_type_handler('string',
'B\StringHandler') in the bootstrap.
The result will be only the second one is working. Also I see more
variations instead of a cleanup.
Working with an IDE, register_primitive_type_handler requires type
hints to use auto completion:
register_primitive_type_handler('string', 'StringHandler');
/* @var $str StringHandler */
$str = 'foobar';
echo $str->length();
vs.
$str = new StringHandler('foobar');
echo $str->length();
Regards,
Thomas
hi,
So function aliases, new open tag and deprecation are bad. What about
the String class?
I think there was some "Let's ... start exploring lighter and more
approachable ways to attack Unicode" on internals ...Unicode is a totally different topic. I would suggest to look at intl
(ICU) extension for a start.Also about cleanup the APIs, take a look at this prototype:
https://github.com/nikic/scalar_objects
This is something that would be much cleaner and without BC problems.
Cheers,
Pierre
@pierrejoye
I think register_primitive_type_handler() is too exclusive:
Hi Thomas, as @nikic noted in the description, it's just a proof of
concept.
hi,
I think register_primitive_type_handler() is too exclusive:
The point of this prototype is to define what is the best APIs we can
create to solve the "inconsistencies"/clean the current API. This
specific function is only a helper here, I do not see it being
implemented core.
Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
sorry, I thought it is sth like session_set_save_handler() ...
Regards,
Thomas
hi,
I think register_primitive_type_handler() is too exclusive:
The point of this prototype is to define what is the best APIs we can
create to solve the "inconsistencies"/clean the current API. This
specific function is only a helper here, I do not see it being
implemented core.Pierre
@pierrejoye | http://blog.thepimp.net | http://www.libgd.org
Hi!
So function aliases, new open tag and deprecation are bad. What about
the String class?
Design it, write it and we'll see how it works. It's not like the
process should start with including it in PHP core. You can write
String class all by yourself, put it on github and once virtually
everybody is using it, we'd gladly discuss including it as a standard
extension.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
You can write String class all by yourself, put it on github and once virtually
everybody is using it, we'd gladly discuss including it as a standard extension.
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();
But that's useless.
It would be great if method calls on primitive types could be supported, like in Nikic' proof of concept (https://github.com/nikic/scalar_objects).
$str = 'my_string_class';
echo $str->length();
I would really like to see that in PHP. It's not only a nicer and shorter way to code but it would also be a solution for the function naming inconsistency ;-)
Best regards
Christian
-----Original Message-----
From: Stas Malyshev [mailto:smalyshev@sugarcrm.com]
Sent: Saturday, January 26, 2013 7:39 PM
To: Thomas Bley
Cc: internals@lists.php.net; Rasmus Lerdorf
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers more attention
Hi!
So function aliases, new open tag and deprecation are bad. What about
the String class?
Design it, write it and we'll see how it works. It's not like the
process should start with including it in PHP core. You can write
String class all by yourself, put it on github and once virtually
everybody is using it, we'd gladly discuss including it as a standard
extension.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();But that's useless.
It would be great if method calls on primitive types could be supported, like in Nikic' proof of concept (https://github.com/nikic/scalar_objects).$str = 'my_string_class';
echo $str->length();I would really like to see that in PHP. It's not only a nicer and shorter way to code but it would also be a solution for the function naming inconsistency ;-)
+1 from that, fortunately since it's an extension it won't be subject to
a vote, you can use it or not. :) The core seems to be heavily
protected by the core developers.
Best regards
Christian
--
-Clint
+1 from that, fortunately since it's an extension it won't be subject to a
vote, you can use it or not. :) The core seems to be heavily protected by
the core developers.
As an APC user, I would be also fine with an extension :-)
@pierre Would it be possible to get windows builds from nikita's repo?
Regards,
Thomas
In userland we can only do something like
$str = new String('my_string_class');
echo $str->length();But that's useless.
It would be great if method calls on primitive types could be supported,
like in Nikic' proof of concept (https://github.com/nikic/scalar_objects).$str = 'my_string_class';
echo $str->length();I would really like to see that in PHP. It's not only a nicer and shorter
way to code but it would also be a solution for the function naming
inconsistency ;-)+1 from that, fortunately since it's an extension it won't be subject to a
vote, you can use it or not. :) The core seems to be heavily protected by
the core developers.Best regards
Christian--
-Clint
Hi
2013/1/25 Damian Tylczyński turneliusz@gmail.com:
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/
There is one really clean solution to this "problem" for the
consistency Guys that tend to complain about PHP endlessly; write the
aliases in PHP that can be included, which can be considered just like
using one of the frameworks thats filled with functions, it can be
written quite fast and you can even use auto_prepend_file to include
it in all scripts.
As said in countless mails above, there is no gain for breaking BC due
to "perfection".
--
regards,
Kalle Sommer Nielsen
kalle@php.net
Hi,
Everyone here forgets that there's a little certification
run by some guys named Zend that factor in some of
these things as well.
That's the point of not having consistency? Checking
if some have better memory that others?
Also, I suppose that everyone can afford to look up
things on the PHP manual when doing debugging on
some crashed remote service via CLI only access.
Now, on a nicer tone.
Consistency across function name/parameters would
help out both new people that learn the language as
well as leave out one point when compared to the other
languages.
Sure, there's no point in changing things just for the
sake of it but I don't get it why this couldn't be a
viable option for PHP 6 for example, which is a major
release.
It would definitely help out new users and get some
bonus points while doing so in order to close the mouth
of those arguing that PHP is so inconsistent in naming
things.
Phil Sturgeon had a nice idea on his blog,
http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind
which I think could very well apply to PHP and maybe
something like this could be done by someone with
less C/PHP internals knowledge that some other
features. If that's the case and all we need is someone
to do the changes, then I could level up my C
knowledge and help out if no one else is willing to do
it.
I'd dislike for it to be rejected with reasons like:
- but it doesn't bring anything new;
- it doesn't help us with anything;
- it doesn't solve real problems;
- the current functions reflect the underlying functions
used. I've been a PHP user (developer) for a couple of
years now and I really don't care what's the parameter
order for the functions that PHP use to help me out
getting my job done; - perfection ain't good.
Best regards.
Florin Patan
https://github.com/dlsniper
Hi
2013/1/25 Damian Tylczyński turneliusz@gmail.com:
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/There is one really clean solution to this "problem" for the
consistency Guys that tend to complain about PHP endlessly; write the
aliases in PHP that can be included, which can be considered just like
using one of the frameworks thats filled with functions, it can be
written quite fast and you can even use auto_prepend_file to include
it in all scripts.As said in countless mails above, there is no gain for breaking BC due
to "perfection".--
regards,Kalle Sommer Nielsen
kalle@php.net
Thank you for the link
http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind I
didn't know that... getters/setters were dumped to the garbage...
http://japfan.pl/uploads/media/dacffbe3073882e86057d04266675637.JPG I
will go get a drink... Is there any log of votes? Like reasons why
"no" people said "no"? Sorry for off-topic. I think I will quit
visiting "internals", this just dosen't make any sense.
2013/1/26 Florin Razvan Patan florinpatan@gmail.com:
Hi,
Everyone here forgets that there's a little certification
run by some guys named Zend that factor in some of
these things as well.That's the point of not having consistency? Checking
if some have better memory that others?Also, I suppose that everyone can afford to look up
things on the PHP manual when doing debugging on
some crashed remote service via CLI only access.Now, on a nicer tone.
Consistency across function name/parameters would
help out both new people that learn the language as
well as leave out one point when compared to the other
languages.Sure, there's no point in changing things just for the
sake of it but I don't get it why this couldn't be a
viable option for PHP 6 for example, which is a major
release.It would definitely help out new users and get some
bonus points while doing so in order to close the mouth
of those arguing that PHP is so inconsistent in naming
things.Phil Sturgeon had a nice idea on his blog,
http://philsturgeon.co.uk/blog/2013/01/php-6-pissing-in-the-wind
which I think could very well apply to PHP and maybe
something like this could be done by someone with
less C/PHP internals knowledge that some other
features. If that's the case and all we need is someone
to do the changes, then I could level up my C
knowledge and help out if no one else is willing to do
it.I'd dislike for it to be rejected with reasons like:
- but it doesn't bring anything new;
- it doesn't help us with anything;
- it doesn't solve real problems;
- the current functions reflect the underlying functions
used. I've been a PHP user (developer) for a couple of
years now and I really don't care what's the parameter
order for the functions that PHP use to help me out
getting my job done;- perfection ain't good.
Best regards.
Florin Patan
https://github.com/dlsniperHi
2013/1/25 Damian Tylczyński turneliusz@gmail.com:
I've seen discussion on reddit
http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/There is one really clean solution to this "problem" for the
consistency Guys that tend to complain about PHP endlessly; write the
aliases in PHP that can be included, which can be considered just like
using one of the frameworks thats filled with functions, it can be
written quite fast and you can even use auto_prepend_file to include
it in all scripts.As said in countless mails above, there is no gain for breaking BC due
to "perfection".--
regards,Kalle Sommer Nielsen
kalle@php.net