Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time. 
http://www.phpsadness.com/sad/4 
http://www.phpsadness.com/sad/15 
http://www.phpsadness.com/sad/27
How about rename all of these functions according to CODING_STANDARD for 
PHP7 
and have aliases for old names? Some names need complete rename, but most of 
them are matter of adding "_".
Function names like phpversion(), htmlentities(), image*() shouldn't be 
kept. IMHO. 
(I repeat. I have no intention removing old names)
str*() would be most difficult. How about rename all of them to str_*()? 
and keep 
libc compatible alias names forever?
Thoughts?
It's last chance for PHP7. 
Sorry that I bring up this topic again, but I couldn't resist. 
If there isn't many objections, I'll write RFC and do all the work needed.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi,
I like this idea. But I'm afraid of BC. There will be some scripts who
won't work after that, because they already use functions with these names.
But since we already have some BC for PHP 7, I think it's about the right
time to do this.
But we have to keep the old names for at least 2 or 3 major versions.
Let's say :
- PHP 7 : We introduce the new functions names
- PHP 8 : We deprecate the old functions names
- PHP 9 : We delete the old functions names.
Regards.
Le Sun, 01 Mar 2015 12:29:49 +0100, Yasuo Ohgaki yohgaki@ohgaki.net a
écrit:
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27How about rename all of these functions according to CODING_STANDARD for
PHP7
and have aliases for old names? Some names need complete rename, but
most of
them are matter of adding "_".Function names like
phpversion(),htmlentities(), image*() shouldn't be
kept. IMHO.
(I repeat. I have no intention removing old names)str*() would be most difficult. How about rename all of them to str_*()?
and keep
libc compatible alias names forever?Thoughts?
It's last chance for PHP7.
Sorry that I bring up this topic again, but I couldn't resist.
If there isn't many objections, I'll write RFC and do all the work
needed.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
-- 
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/
How about rename all of these functions according to CODING_STANDARD
for
PHP7
and have aliases for old names?
If this list had an FAQ (which I think it should), this would be on it.
The answer is no, it's just not worth it. Having a function called str_pos which is an alias of strpos, but only on some versions, is more confusing, not less.
Some people, such as the author of phpsadness.com, enjoy ranting about things, and would probably find a way to be as critical of the new aliases as the current names.
Regards,
Rowan Collins 
[IMSoP]
How about rename all of these functions according to CODING_STANDARD
for
PHP7
and have aliases for old names?If this list had an FAQ (which I think it should), this would be on it.
The answer is no, it's just not worth it. Having a function called str_pos which is an alias of strpos, but only on some versions, is more confusing, not less.
My sentiment too. Factor in that someone already using the proposed 
himself, things can only go south from here.
If PHP wants to clean up, then do it right: use a namespace for it.
- Markus
Maybe better implement for method calls on primitive types in PHP 7? 
https://github.com/nikic/scalar_objects
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objects
We'd have a whole bunch of tough decisions to make - does HTML escaping really belong as a method of the string type? What are printf and scanf methods of? Etc
Without the ability for a user to patch the existing type (a major departure from current classes), you basically still have a bunch of function aliases. What motivation would there be to change dozens of instances of strpos($a, $b) to $a->indexOf($b)?
In this respect, some version of UString makes more sense, because (if well-defined) it actually gives users some advantage over the current functions.
Regards,
Rowan Collins 
[IMSoP]
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objectsWe'd have a whole bunch of tough decisions to make - does HTML escaping really belong as a method of the string type? What are printf and scanf methods of? Etc
Without the ability for a user to patch the existing type (a major departure from current classes), you basically still have a bunch of function aliases. What motivation would there be to change dozens of instances of strpos($a, $b) to $a->indexOf($b)?
This could be implemented but the existing functions (eg strpos()) could be left.
This would set the model for new functions on basic types, etc, to be 
implemented as methods.
If replacing strlen($str) by $str.length is really wanted, then allow a very long 
cross over time so that people do not need 2 versions of their code: 1 for 
method calls & the other basic functions. Thus if this were implemented in, say, 
PHP 7 warnings would be generated by default in PHP 9 and removal in PHP 11.
It would, however, almost create a new language ... or what feels like a new language.
In this respect, some version of UString makes more sense, because (if well-defined) it actually gives users some advantage over the current functions.
-- 
Alain Williams 
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. 
+44 (0) 787 668 0256  http://www.phcomp.co.uk/ 
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php 
#include <std_disclaimer.h
Hi Rowan,
On Mon, Mar 2, 2015 at 2:22 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objectsWe'd have a whole bunch of tough decisions to make - does HTML escaping
really belong as a method of the string type? What are printf and scanf
methods of? EtcWithout the ability for a user to patch the existing type (a major
departure from current classes), you basically still have a bunch of
function aliases. What motivation would there be to change dozens of
instances of strpos($a, $b) to $a->indexOf($b)?In this respect, some version of UString makes more sense, because (if
well-defined) it actually gives users some advantage over the current
functions.
I agree. We may improve "string" as well, but comprehensive UString 
implementation would be better. 
Regardless of new APIs for strings, old string APIs will remain and other 
APIs remain. We are better 
to clean up anyway, IMHO.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objects
I've searched through the internals archive looking for debate on using 
scalar objects without much luck.  I'd love to see some discussion around 
this as it seems like it would go a long way to resolving some common pain 
points in PHP without BC like:
- type hints
- inconsistant function naming
- needle/haystack
- unicode
And, the method chaining of common string/array manipulations makes for 
cleaner, easier to read code.
I've used the scalar objects extension and found it a pleasure to use over 
the standard function but I can't use it in my larger client projects due 
to it not being in the core and it's experimental status.
2015-03-02 2:17 GMT+02:00 Terry Cullen terry@terah.com.au:
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objectsI've searched through the internals archive looking for debate on using
scalar objects without much luck. I'd love to see some discussion around
this as it seems like it would go a long way to resolving some common pain
points in PHP without BC like:
- type hints
- inconsistant function naming
- needle/haystack
- unicode
And, the method chaining of common string/array manipulations makes for
cleaner, easier to read code.
+1
Hi all,
2015-03-02 2:17 GMT+02:00 Terry Cullen terry@terah.com.au:
Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objectsI've searched through the internals archive looking for debate on using
scalar objects without much luck. I'd love to see some discussion around
this as it seems like it would go a long way to resolving some common
pain
points in PHP without BC like:
- type hints
- inconsistant function naming
- needle/haystack
- unicode
And, the method chaining of common string/array manipulations makes for
cleaner, easier to read code.+1
I'm strong supporter for scalar objects also.
I still would like to clean up old function names, like phpversion()/etc. 
I did this for pgsql module large object functions about 10 years ago. 
It worked well enough. IMHO.
http://php.net/manual/en/function.pg-lo-open.php 
pg_lo_open() was named pg_loopen(). The old name aliases, pg_loopen()/etc, 
are 
available now, too.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Markus and Fischer,
How about rename all of these functions according to CODING_STANDARD
for
PHP7
and have aliases for old names?If this list had an FAQ (which I think it should), this would be on it.
The answer is no, it's just not worth it. Having a function called
str_pos which is an alias of strpos, but only on some versions, is more
confusing, not less.My sentiment too. Factor in that someone already using the proposed
himself, things can only go south from here.If PHP wants to clean up, then do it right: use a namespace for it.
I agree use of namespace is better solution. It's rather severe BC, though. 
How about rename functions except "string" and "array" related functions?
BTW, I cannot change document system, but I'm going to update all doc 
contents if this passes.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hello!
The answer is no, it's just not worth it. Having a function called
str_pos which is an alias of strpos, but only on some versions, is more
confusing, not less.My sentiment too. Factor in that someone already using the proposed
himself, things can only go south from here.If PHP wants to clean up, then do it right: use a namespace for it.
I agree use of namespace is better solution. It's rather severe BC, though.
How about rename functions except "string" and "array" related functions?BTW, I cannot change document system, but I'm going to update all doc
contents if this passes.
I'm not sure we're on the same page. I'm talking about moving in 
"no-BC-break" way, if at all. That is, no existing function be touched.
As to whether namespaces-aliases are really necessary I leave for others.
I think a sensible thing to do at this stage would be, rather than 
changing existing stuff, laying the ground work how to do it in the 
future. What I mean is: an RFC for consistent introducing new "names" in 
the PHP language.
So that /future/ functionality does not always get slapped into the 
global namespace but that we finally start using our reserved PHP
namespace and put stuff in there instead of the global pollution.
Yeah, I think that direction is a sensible start and gather peoples 
mindset about this instead of going backwards, renaming stuff without 
clear plan, etc.
thank you,
- Markus
Hi Markus,
The answer is no, it's just not worth it. Having a function called
str_pos which is an alias of strpos, but only on some versions, is more
confusing, not less.My sentiment too. Factor in that someone already using the proposed
himself, things can only go south from here.If PHP wants to clean up, then do it right: use a namespace for it.
I agree use of namespace is better solution. It's rather severe BC,
though.
How about rename functions except "string" and "array" related functions
?BTW, I cannot change document system, but I'm going to update all doc
contents if this passes.I'm not sure we're on the same page. I'm talking about moving in
"no-BC-break" way, if at all. That is, no existing function be touched.
I would love to have namespace that could be imported like
namespace \php\7\function* as ; // Import all functions to 
namespace \php\7\function* as ;
and have INI like
default_namespaces "\php\7\function* \php\5\function*"
This way, we'll have no-BC since user can select functions to import. 
(Namespace layout should be improved. Above example will have issues 
most certainly)
Your idea is similar to this, I guess.
As to whether namespaces-aliases are really necessary I leave for others.
I think a sensible thing to do at this stage would be, rather than
changing existing stuff, laying the ground work how to do it in the
future. What I mean is: an RFC for consistent introducing new "names" in
the PHP language.So that /future/ functionality does not always get slapped into the
global namespace but that we finally start using our reserved PHP
namespace and put stuff in there instead of the global pollution.Yeah, I think that direction is a sensible start and gather peoples
mindset about this instead of going backwards, renaming stuff without
clear plan, etc.
We may postpone some renames. 
I wrote almost complete list. Please take a look at
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
There are many functions that can have aliases safely. 
I'll post [RFC][DISCUSSION] now. Please comment on new thread!
Thank you.
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
I wrote almost complete list. Please take a look at
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
While the idea of this is well meant, this is another major problem for 
developers working with substantial legacy code yet needing to update 
third party libraries. The statement "You can use old names for good." 
is all very well, but if one library has been 'modernised and another 
not, one has to work with both sets of names in parallel ... or maintain 
legacy copies of the same libraries.
Updating the PHP documentation is all very well, but how about 
tutorials, books, third party tools and so on. I would still like some 
help to update PHPEclipse to the recent PHP5 changes without having to 
code a complete new set of reserved words and highlighting ... ore 
reason to simply ditch PHP7 ...
-- 
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
Hi Lester,
I wrote almost complete list. Please take a look at
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
While the idea of this is well meant, this is another major problem for
developers working with substantial legacy code yet needing to update
third party libraries. The statement "You can use old names for good."
is all very well, but if one library has been 'modernised and another
not, one has to work with both sets of names in parallel ... or maintain
legacy copies of the same libraries.
I think old function names should exist forever, so there wouldn't be 
issue you mentioned.
Updating the PHP documentation is all very well, but how about
tutorials, books, third party tools and so on. I would still like some
help to update PHPEclipse to the recent PHP5 changes without having to
code a complete new set of reserved words and highlighting ... ore
reason to simply ditch PHP7 ...
Old names works. No one forces users to use new names. 
I'll update PHP documents. It's a lot of work, but I'll. 
3rd party documents may be update if they would like to.
The issue here is PHP will keep inconsistent names forever or not. 
IMHO.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
I think old function names should exist forever, so there wouldn't be
issue you mentioned.
...
The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Have you noticed the slight contradiction here? You want to get rid of 
the inconsistent names, but you propose to keep the old, inconsistent, 
names around forever. And then you want to add more names, so that 
people can inconsistently use a different name for the same thing.
We all wish we could go back in time and tell Rasmus to choose better 
names (probably including Rasmus himself; no ill will intended!), but 
just adding some slightly different names for the same things will 
muddle people more, not less.
I'm sorry, but this isn't going to be any more popular a suggestion than 
the last ten times it was proposed.
Regards,
-- 
Rowan Collins 
[IMSoP]
Hi Rowan,
On Tue, Mar 3, 2015 at 7:40 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Have you noticed the slight contradiction here? You want to get rid of the
inconsistent names, but you propose to keep the old, inconsistent, names
around forever. And then you want to add more names, so that people can
inconsistently use a different name for the same thing.
I should have written "PHP will keep only inconsistent names forever or 
not". 
My proposal is to have consistent names that accord CORDING_STARNDARDS, 
not eliminating inconsistent names.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Rowan,
On Tue, Mar 3, 2015 at 7:40 AM, Rowan Collins rowan.collins@gmail.com
wrote:The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Have you noticed the slight contradiction here? You want to get rid of the
inconsistent names, but you propose to keep the old, inconsistent, names
around forever. And then you want to add more names, so that people can
inconsistently use a different name for the same thing.I should have written "PHP will keep only inconsistent names forever or
not".
My proposal is to have consistent names that accord CORDING_STARNDARDS,
not eliminating inconsistent names.
Seriously, let call them exceptions to the CS and move on. I do think 
that doing that will create even more mess that what we actually try 
to solve.
For the extension, it is relatively easier to actually provide more 
clean and modern APIs when possible. For the core, leaving them like 
that is simply the best move. And let focus on the scalar object-like 
proposal.
-- 
Pierre
@pierrejoye | http://www.libgd.org
Old names works. No one forces users to use new names.
I'll update PHP documents. It's a lot of work, but I'll.
3rd party documents may be update if they would like to.
Some developers will drop PHP5 support for third party libraries in much 
the same way as they will enable 'strict' by default. WE have no 
control over that other than either maintaining our own version of the 
same libraries or simply not bothering to risk the problems of 
upgrading. "No one forces users to use new names" is simply burying head 
in sand ... there will be those who insist that names must be changed if 
the 'modern way' is made available.
The issue here is PHP will keep inconsistent names forever or not.
IMHO.
Some of the extensions that you want to rename could be provided as 
completely self contained replacements if that is what people need, and 
at the same time restructure the parameters to be 'more consistent' 
leaving the legacy suite in place. The suggestion has been made many 
times that an alternate string or array extension as an option would be 
a lot more practical and then a legacy build can be maintained.
gd is probably a good case for that approach, as some of us still use 
imagick to provide the same facilities anyway, or gmagick or magickwand 
and changing the cross reference charts from gd will not be helpful.
-- 
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
Hi!
I would love to have namespace that could be imported like
namespace \php\7\function* as ; // Import all functions to
namespace \php\7\function* as ;
Please no. When we designed namespaces, we explicitly omitted bulk 
imports, and the reasons that were true then are still true now. Bulk 
imports are a road to a huge mess and return to the same problem 
namespaces were created to fix.
-- 
Stas Malyshev 
smalyshev@gmail.com
I can't think of any good use case for a bulk import outside of laziness. 
Any good IDE will handle this for you and if you are importing as \ then 
why don't you just not namespace them in the first place.
On Mon, Mar 2, 2015 at 11:33 PM, Stanislav Malyshev smalyshev@gmail.com 
wrote:
Hi!
I would love to have namespace that could be imported like
namespace \php\7\function* as ; // Import all functions to
namespace \php\7\function* as ;Please no. When we designed namespaces, we explicitly omitted bulk
imports, and the reasons that were true then are still true now. Bulk
imports are a road to a huge mess and return to the same problem
namespaces were created to fix.--
Stas Malyshev
smalyshev@gmail.com
Hi Michael,
On Tue, Mar 3, 2015 at 3:03 PM, Michael Schuett michaeljs1990@gmail.com 
wrote:
I can't think of any good use case for a bulk import outside of laziness.
Any good IDE will handle this for you and if you are importing as \ then
why don't you just not namespace them in the first place.
Bulk import is not important part. 
Import to root namespace is required to have clean "" namespace without 
breaking "old code". We don't have this currently. If we force user to 
rewrite old 
code, it is not needed.
Let me rephrase, we have module functions/classes defined under "". 
Therefore, 
we'll break almost all apps if we define module functions/classes under 
"\php\somewhere".
It's just an option to cleanup legacy function/class/interface/etc without 
BC. I'm not 
enthusiastic for it even if it could give us a lot freedom for API redesign 
without BC. 
(at least for now)
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
hi,
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27How about rename all of these functions according to CODING_STANDARD for
PHP7
and have aliases for old names? Some names need complete rename, but most of
them are matter of adding "_".Function names like
phpversion(),htmlentities(), image*() shouldn't be
kept. IMHO.
(I repeat. I have no intention removing old names)str*() would be most difficult. How about rename all of them to str_*()?
and keep
libc compatible alias names forever?Thoughts?
I see no gain to do that. It also won't solve the arguments order mess.
The last time we discuss this topic the idea was to go for the new 
pseudo object for most scalar, something Nikita worked on with a 
prototype, allowing something like $mystring->replace(...); But adding 
name aliases only to get names_defined_correctly sounds like a bad 
move to me.
Cheers, 
Pierre
Hi Pierre,
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27How about rename all of these functions according to CODING_STANDARD for
PHP7
and have aliases for old names? Some names need complete rename, but
most of
them are matter of adding "_".Function names like
phpversion(),htmlentities(), image*() shouldn't be
kept. IMHO.
(I repeat. I have no intention removing old names)str*() would be most difficult. How about rename all of them to str_*()?
and keep
libc compatible alias names forever?Thoughts?
I see no gain to do that. It also won't solve the arguments order mess.
The last time we discuss this topic the idea was to go for the new
pseudo object for most scalar, something Nikita worked on with a
prototype, allowing something like $mystring->replace(...); But adding
name aliases only to get names_defined_correctly sounds like a bad
move to me.
Sadly, this proposal only renames functions and has aliases for old names. 
We may try to fix argument order mess when we have "default namespace"! 
I just don't have time to do all the job at once...
I posted [RFC][DISCUSSION] as new thread. Please look at the list of rename 
candidates. I think you'll agree to rename most of them.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Pierre,
Hi all,
First of all, I have no intention removing old function names.
PHP function names are subject of critics for a long time.
http://www.phpsadness.com/sad/4
http://www.phpsadness.com/sad/15
http://www.phpsadness.com/sad/27How about rename all of these functions according to CODING_STANDARD for
PHP7
and have aliases for old names? Some names need complete rename, but
most of
them are matter of adding "_".Function names like
phpversion(),htmlentities(), image*() shouldn't be
kept. IMHO.
(I repeat. I have no intention removing old names)str*() would be most difficult. How about rename all of them to str_*()?
and keep
libc compatible alias names forever?Thoughts?
I see no gain to do that. It also won't solve the arguments order mess.
The last time we discuss this topic the idea was to go for the new
pseudo object for most scalar, something Nikita worked on with a
prototype, allowing something like $mystring->replace(...); But adding
name aliases only to get names_defined_correctly sounds like a bad
move to me.Sadly, this proposal only renames functions and has aliases for old names.
We may try to fix argument order mess when we have "default namespace"!
I just don't have time to do all the job at once...I posted [RFC][DISCUSSION] as new thread. Please look at the list of rename
candidates. I think you'll agree to rename most of them.
Sorry, I do not see how a new thread helps. Namespace either. These 
will only be duplicated APIs for little to no gain. Existing codes 
won't move as they won't be compatible with 5.x.
We should really consider Nikita's experiment instead,as it acutally 
brings some big plus. Simple aliases for the sake of having _ in the 
names bring nothing but confusion in my humble opinion.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Sorry, I do not see how a new thread helps. Namespace either. These
will only be duplicated APIs for little to no gain. Existing codes
won't move as they won't be compatible with 5.x.We should really consider Nikita's experiment instead,as it acutally
brings some big plus. Simple aliases for the sake of having _ in the
names bring nothing but confusion in my humble opinion.Cheers,
This topic has come up many times, and that is always the answer.  We 
should look at something meaningful (methods on scalars, which 
eliminates the parameter order issue as well) rather than just duplicate 
function names.
This is at least the third time we've had this thread and come to that 
same statement.  I agree with it.
So what's the blocker on discussing Nikita's work for core?
--Larry Garfield
Hi Larry,
On Tue, Mar 3, 2015 at 7:22 AM, Larry Garfield larry@garfieldtech.com 
wrote:
Sorry, I do not see how a new thread helps. Namespace either. These
will only be duplicated APIs for little to no gain. Existing codes
won't move as they won't be compatible with 5.x.We should really consider Nikita's experiment instead,as it acutally
brings some big plus. Simple aliases for the sake of having _ in the
names bring nothing but confusion in my humble opinion.Cheers,
This topic has come up many times, and that is always the answer. We
should look at something meaningful (methods on scalars, which eliminates
the parameter order issue as well) rather than just duplicate function
names.This is at least the third time we've had this thread and come to that
same statement. I agree with it.So what's the blocker on discussing Nikita's work for core?
I like scalar objects, but it does not resolve that PHP has non standard 
function names. 
It does not change old names, therefore it's impossible to resolve issue. 
This is the reason why I'm proposing while I like scalar object, use of 
namespace, etc.
Many of proposed candidates have nothing to do with scalar object also.
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed 
Functions other than Standard module
http://php.net/manual/en/book.sockets.php 
socket_get_peer_name ← socket_getpeername 
socket_get_sock_name ← socket_getsockname 
socket_recv_from ← socket_recvfrom 
socket_recv_msg ← socket_recvmsg 
socket_send_msg ← socket_sendmsg 
socket_send_to ← socket_sendto 
socket_error_str ← socket_strerror (Adjust to accord with other function 
names. e.g. bz_error_str()) 
http://php.net/manual/en/book.bc.php 
bc_add ← bcadd 
bc_comp ← bccomp 
bc_div ← bcdiv 
bc_mod ← bcmod 
bc_mul ← bcmul 
bc_pow ← bcpow 
bc_pow_mod ← bcpowmod 
bc_scale ← bcscale 
bc_sqrt ← bcsqrt 
bc_sub ← bcsub 
http://php.net/manual/en/book.gettext.php 
gettext_bind_text_domain_codeset ← bind_textdomain_codeset 
gettext_bind_text_domain ← bindtextdomain 
gettext_dc ← dcgettext 
gettext_dcn ← dcngettext 
gettext_d ← dgettext 
gettext_dn ← dngettext 
gettext_n ← ngettext 
gettext_text_domain ← textdomain 
http://php.net/manual/en/book.bzip2.php 
bz_close → bzclose 
bz_compress → bzcompress 
bz_decompress → bzdecompress 
bz_errno → bzerrno 
bz_error → bzerror 
bz_error_str → bzerrstr 
bz_flush → bzflush 
bz_open → bzopen 
bz_read → bzread 
bz_write → bzwrite 
http://php.net/manual/en/book.zlib.php 
gz_close → gzclose 
gz_compress → gzcompress 
gz_decode → gzdecode 
gz_deflate → gzdeflate 
gz_encode → gzencode 
gz_eof → gzeof 
gz_file → gzfile 
gz_getc → gzgetc 
gz_gets → gzgets 
gz_getss → gzgetss 
gz_inflate → gzinflate 
gz_open → gzopen 
gz_passthru → gzpassthru 
gz_puts → gzputs 
gz_read → gzread 
gz_rewind → gzrewind 
gz_seek → gzseek 
gz_tell → gztell 
gz_uncompress → gzuncompress 
gz_write → gzwrite 
gz_read_file → readgzfile 
http://php.net/manual/en/book.image.php 
gd_image_size → getimagesize 
gd_image_size_from_string → getimagesizefromstring 
gd_type_to_extension → image_type_to_extension 
gd_type_to_mime_type → image_type_to_mime_type 
gd_2wbmp → image2wbmp 
gd_affine → imageaffine 
gd_affine_matrix_concat → imageaffinematrixconcat 
gd_affine_matrix_get → imageaffinematrixget 
gd_alpha_blending → imagealphablending 
gd_antialias → imageantialias 
gd_arc → imagearc 
gd_char → imagechar 
gd_charup → imagecharup 
gd_color_allocate → imagecolorallocate 
gd_color_allocate_alpha → imagecolorallocatealpha 
gd_color_at → imagecolorat 
gd_color_closest → imagecolorclosest 
gd_color_closest_alpha → imagecolorclosestalpha 
gd_color_closest_hwb → imagecolorclosesthwb 
gd_color_deallocate → imagecolordeallocate 
gd_color_exact → imagecolorexact 
gd_color_exact_alpha → imagecolorexactalpha 
gd_color_match → imagecolormatch 
gd_color_resolve → imagecolorresolve 
gd_color_resolve_alpha → imagecolorresolvealpha 
gd_color_set → imagecolorset 
gd_colors_for_index → imagecolorsforindex 
gd_colors_total → imagecolorstotal 
gd_color_transparent → imagecolortransparent 
gd_convolution → imageconvolution 
gd_copy → imagecopy 
gd_copy_merge → imagecopymerge 
gd_copy_merge_gray → imagecopymergegray 
gd_copy_resampled → imagecopyresampled 
gd_copy_resized → imagecopyresized 
gd_create → imagecreate 
gd_create_from_gd2 → imagecreatefromgd2 
gd_create_from_gd2_part → imagecreatefromgd2part 
gd_create_from_gd → imagecreatefromgd 
gd_create_from_gif → imagecreatefromgif 
gd_create_from_jpeg → imagecreatefromjpeg 
gd_create_from_png → imagecreatefrompng 
gd_create_from_string → imagecreatefromstring 
gd_create_from_wbmp → imagecreatefromwbmp 
gd_create_from_webp → imagecreatefromwebp 
gd_create_from_xbm → imagecreatefromxbm 
gd_create_from_xpm → imagecreatefromxpm 
gd_create_true_color → imagecreatetruecolor 
gd_crop → imagecrop 
gd_crop_auto → imagecropauto 
gd_dashed_line → imagedashedline 
gd_destroy → imagedestroy 
gd_ellipse → imageellipse 
gd_fill → imagefill 
gd_filled_arc → imagefilledarc 
gd_filled_ellipse → imagefilledellipse 
gd_filled_polygon → imagefilledpolygon 
gd_filled_rectangle → imagefilledrectangle 
gd_fill_to_border → imagefilltoborder 
gd_filter → imagefilter 
gd_flip → imageflip 
gd_font_height → imagefontheight 
gd_font_width → imagefontwidth 
gd_ft_bbox → imageftbbox 
gd_ft_text → imagefttext 
gd_gamma_correct → imagegammacorrect 
gd_raw2 → imagegd2 
gd_raw → imagegd 
gd_gif → imagegif 
gd_grab_screen → imagegrabscreen 
gd_grab_window → imagegrabwindow 
gd_interlace → imageinterlace 
gd_is_true_color → imageistruecolor 
gd_jpeg → imagejpeg 
gd_layer_effect → imagelayereffect 
gd_line → imageline 
gd_load_font → imageloadfont 
gd_palette_copy → imagepalettecopy 
gd_palette_to_true_color → imagepalettetotruecolor 
gd_png → imagepng 
gd_polygon → imagepolygon 
gd_ps_bbox → imagepsbbox 
gd_ps_encode_font → imagepsencodefont 
gd_ps_extend_font → imagepsextendfont 
gd_ps_free_font → imagepsfreefont 
gd_ps_load_font → imagepsloadfont 
gd_ps_slant_font → imagepsslantfont 
gd_ps_text → imagepstext 
gd_rectangle → imagerectangle 
gd_rotate → imagerotate 
gd_save_alpha → imagesavealpha 
gd_scale → imagescale 
gd_set_brush → imagesetbrush 
gd_set_interpolation → imagesetinterpolation 
gd_set_pixel → imagesetpixel 
gd_set_style → imagesetstyle 
gd_set_thickness → imagesetthickness 
gd_set_tile → imagesettile 
gd_string → imagestring 
gd_string_up → imagestringup 
gd_width → imagesx 
gd_height → imagesy 
gd_true_color_to_palette → imagetruecolortopalette 
gd_ttf_bbox → imagettfbbox 
gd_ttf_text → imagettftext 
gd_types → imagetypes 
gd_wbmp → imagewbmp 
gd_webp → imagewebp 
gd_xbm → imagexbm 
gd_iptc_embed → iptcembed 
gd_iptc_parse → iptcparse 
gd_jpeg2wbmp → jpeg2wbmp 
gd_png2wbmp ??? png2wbmp 
http://php.net/manual/en/book.exif.php 
exif_image_type → exif_imagetype 
exif_tag_name → exif_tagname 
http://php.net/manual/en/book.mbstring.php 
mb_decode_mime_header → mb_decode_mimeheader 
mb_decode_numeric_entity → mb_decode_numericentity 
mb_encode_mime_header → mb_encode_mimeheader 
mb_encode_numeric_entity → mb_encode_numericentity 
Date/Time related: 
http://php.net/manual/en/book.datetime.php 
date_format → date (Return formatted date string of timestamp) 
date_get → getdate (Return array date) 
date_check → checkdate 
time_part → idate (Retrieve part of date information as int according to 
format) 
time → time (The same as it is now. Return int timestamp) 
time_make → mktime (Return timestamp from number of int parameters) 
time_format → strftime (Return lobal time string according to format/locale) 
time_utc → gmdate (Return array GMT/UTC timestamp) 
time_utc_make → gmmktime (Return GMT/UTC timestamp from array) 
time_utc_format → gmstrftime (Return GMT/UTC time string according to 
format/locale) 
time_get → gettimeofday (Return array time of day) 
time_local → localtime (Return localtime() result array. More info than 
time_get/gettimeofday) 
time_micro → microtime (Return microtime resolution time) 
time_parse → strptime (Parse time string generated by time_format/strftime. 
Return timestamp) 
time_from_string → strtotime (Parse string time and return timestamp. 
Return timestamp) 
http://php.net/manual/en/book.apache.php 
sapi_request_headers → getallheaders (Categorized as apache function, but 
available for CLI and FCGI also) 
apache_virtual → virtual 
apache_get_env → apache_getenv 
apache_set_env → apache_setenv 
"String" functions
http://php.net/ref.strings 
HTML related: 
html_entities → htmlentities 
html_escape → htmlspecialchars (Rename it with real meaning) 
html_escape_decode → htmlspecialchars_decode 
html_nl2br → nl2br 
html_strip_tags → strip_tags 
Locate related: 
locale_conv → localeconv 
locale_set → setlocale 
“string” function but no “str_” prefix 
str_cslashes → addcslashes 
str_cslashes_strip → stripcslashes 
str_slashes → addslashes 
str_slashes_strip → stripslashes 
str_count_chars → count_chars 
str_explode → explode 
str_implode → implode 
str_money_format → money_format 
str_number_format → number_format 
str_levenshtein → levenshtein 
str_metaphone → metaphone 
str_parse → parse_str 
str_quote_meta → quotemeta 
str_similar_text → similar_text 
str_soundex → soundex 
str_sscanf → sscanf 
str_rtrim → rtrim 
str_trim → trim 
str_ltrim → ltrim 
str_lc_first → lcfirst 
str_uc_first → ucfirst 
str_uc_words → ucwords 
str_word_wrap → wordwrap 
Comparison: 
str_cmp → strcmp 
str_ncmp → strncmp 
str_case_cmp → strcasecmp 
str_ncase_cmp → strncasecmp 
str_nat_cmp → strnatcmp 
str_nat_case_cmp → strnatcasecmp 
Conversion: 
str_to_lower → strtolower 
str_to_upper → strtoupper 
Misc: 
str_get_csv → str_getcsv 
Named after libc: 
ord → ord (Keep as it is now) 
chr → chr (Keep as it is now. str_chr() is strstr() alias.) 
str_chr → strchr 
str_cmp → strcmp 
str_coll → strcoll 
str_cspn → strcspn 
str_ipos → stripos 
str_istr → stristr 
str_len → strlen 
str_pbrk → strpbrk 
str_pos → strpos 
str_rchr → strrchr 
str_rev → strrev 
str_ripos → strripos 
str_rpos → strrpos 
str_spn → strspn 
str_str → strstr 
str_tok → strtok 
str_tr → strtr 
http://php.net/manual/en/book.mbstring.php 
mb_str_cut → mb_strcut 
mb_strim_width → mb_strimwidth 
mb_str_ipos → mb_stripos 
mb_str_istr → mb_stristr 
mb_str_len → mb_strlen 
mb_str_pos → mb_strpos 
mb_str_rchr → mb_strrchr 
mb_str_richr → mb_strrichr 
mb_str_ripos → mb_strripos 
mb_str_rpos → mb_strrpos 
mb_str_str → mb_strstr 
mb_str_to_lower → mb_strtolower 
mb_str_to_upper → mb_strtoupper 
mb_str_width → mb_strwidth 
http://php.net/manual/en/book.iconv.php 
iconv_str_len → iconv_strlen 
iconv_str_pos → iconv_strpos 
iconv_str_rpos → iconv_strrpos 
http://php.net/manual/en/book.intl.php 
grapheme_str_ipos → grapheme_stripos 
grapheme_str_istr → grapheme_stristr 
grapheme_str_len → grapheme_strlen 
grapheme_str_pos → grapheme_strpos 
grapheme_str_ripos → grapheme_strripos 
grapheme_str_rpos → grapheme_strrpos 
grapheme_str_str → grapheme_strstr 
"Array" functions
http://php.net/manual/en/ref.array.php 
array_sort → sort (Sort values) 
array_sort_reverse → rsort (Reverse sort values) 
array_sort_user → usort (User sort values) 
array_sort_assoc → asort (Keep key and sort) 
array_sort_assoc_reverse → arsort (Keep key and reverse sort) 
array_sort_assoc_user → uasort (Keep key and user sort) 
array_sort_key → ksort (Sort keys) 
array_sort_key_reverse → krsort (Reverse sort keys) 
array_sort_key_user → uksort (User key sort) 
array_sort_natual → natsort (Natural sort) 
array_sort_natual_case → natcasesort (Natural sort without case) 
array_in → in_array 
array_range → range (Create array of range) 
array_shuffle → shuffle (Randomize values) 
Other than "string" and "array" standard module functions
http://php.net/manual/en/book.misc.php 
time_sleep ← sleep 
time_nano_sleep ← time_nanosleep 
time_micro_sleep ← usleep 
time_unique_id ← uniqid (uniqid() is microtime() based) 
sys_get_load_avg ← sys_getloadavg 
php_strip_white_space ← php_strip_whitespace 
http://php.net/manual/en/book.url.php 
url_decode ← urldecode 
url_encode ← urlencode 
url_raw_decode ← rawurldecode 
url_raw_encode ← rawurlencode 
url_parse ← parse_url 
url_build_query ← http_build_query (Make it URL function) 
http://php.net/manual/en/ref.info.php 
php_credits ← phpcredits 
php_info ← phpinfo 
php_version ← phpversion 
get_last_mod ← getlastmod (Return main script timestamp.) 
get_my_gid ← getmygid (“my_” prefix used because they return info about 
current script.) 
get_my_inode ← getmyinode 
get_my_pid ← getmypid 
get_my_uid ← getmyuid 
get_rusage ← getrusage 
get_opt ← getopt 
get_env ← getenv 
put_env ← putenv 
http://php.net/manual/en/book.var.php 
bool_val ← boolval 
double_val ← doubleval 
float_val ← floatval 
int_val ← intval 
str_val ← strval 
get_type ← gettype 
set_type ← settype 
is_set ← isset (There are number of is_(). e.g.is_int()/is_string()/etc) 
http://php.net/manual/en/ref.exec.php 
exec ← exec (exec() remains as it is) 
exec_passthru ← passthru (Named after exec()) 
exec_shell ← shell_exec 
exec_system ← system 
exec_escape_arg ← escapeshellarg 
exec_escape_cmd ← escapeshellcmd 
http://php.net/manual/en/ref.filesystem.php 
disk_free_space ← diskfreespace 
link ← link (The same as now) 
link_info ← linkinfo 
link_stat ← lstat 
link_chown ← lchown 
link_chgrp ← lchgrp 
link_read ← readlink 
link_symbolic ← symlink 
path_base_name ← basename 
path_info ← pathinfo 
read_file ← readfile (This could be file_read() or file_passthru(), but 
file_read() conflict with fread(), file_passthru() conflict with 
fpassthru(). Any good name?) 
pipe_close ← pclose 
pipe_open ← popen 
realpath related : Could be as it is now? 
realpath ← realpath 
realpath_cache_get ← realpath_cache_get 
realpath_cache_size ← realpath_cache_size 
file_atime ← fileatime 
file_ctime ← filectime 
file_group ← filegroup 
file_inode ← fileinode 
file_mtime ← filemtime 
file_owner ← fileowner 
file_perms ← fileperms 
file_size ← filesize 
file_type ← filetype 
file_name_match ← fnmatch 
file_temp_name ← tempnam 
file_copy ← copy 
file_stat() ← stat() 
file_stat_clear_cache ← clearstatcache 
f() : Prefixed by file_? - It's supposed to be named as “file module”. If 
“f” prefix is kept, there should be “ftmp(tmpfile)”,“frewind(rewind)” 
because these operates with file handle. 
file_open ← fopen 
file_close ← fclose 
file_eof ← feof 
file_flush ← fflush 
file_getc ← fgetc 
file_get_csv ← fgetcsv 
file_gets ← fgets 
file_getss ← fgetss 
file_passthru ← fpassthru 
file_put_csv ← fputcsv 
file_puts ← fputs 
file_read ← fread 
file_scanf ← fscanf 
file_seek ← fseek 
file_stat ← fstat 
file_tell ← ftell 
file_truncate ← ftruncate 
file_write ← fwrite 
file_rewind ← rewind (This one is exception that does not have “f” prefix, 
but returns file handle) 
file_temp ← tmpfile (This one is exception that does not have “f” prefix, 
but operates with file handle) 
file_delete ← unlink (There is dummy “delete()” function entry for 
unlink(). Unlink is a directory operation in fact, but made it as 
file_delete(). There will be dir_delete()) 
Directory related : Prefixed by dir_? It's supposed to be named as “dir 
module” 
dir_name ← dirname 
dir_glob ← glob 
dir_rename ← rename (Rename is actually a directory operation. e.g File 
deletion/rename is controlled by current dir permission) 
dir_delete ← rmdir 
dir_create ← mkdir 
dir_chown ← chown 
dir_chmod ← chmod 
dir_chgrp ← chgrp 
Methods
StdClass::__setState() ← StdClass::__set_state() → 
SessionIdInterface::createSid() ← SessionIdInterface::create_sid()
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.
Again, you're contradicting yourself here - you can't say that your 
mission is to change the old names, rather than offer an alternative, 
but then also say that the old names will stay around forever. If both 
names exist, that's exactly what you've created - an alternative.
If we're going to have an alternative, let's come up with a creative 
alternative that actually has an advantage to using it, not a choice 
between equally cryptic names like "strripos" vs "str_ripos".
Regards,
-- 
Rowan Collins 
[IMSoP]
Hi Rowan,
On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.Again, you're contradicting yourself here - you can't say that your
mission is to change the old names, rather than offer an alternative, but
then also say that the old names will stay around forever. If both names
exist, that's exactly what you've created - an alternative.
I think there is big difference between new API and alias. 
Alias is just a copy, new API works differently.
If we're going to have an alternative, let's come up with a creative
alternative that actually has an advantage to using it, not a choice
between equally cryptic names like "strripos" vs "str_ripos".
I don't like the name neither. I improved other names such as 
"array_sort_assoc_reverse → arsort" , 
but I kept cryptic libc names.
Suggestions are appreciated for cryptic names. 
I think "gettext_d" is equally bad, for example...
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Rowan,
On Tue, Mar 3, 2015 at 7:50 AM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:I like scalar objects, but it does not resolve that PHP has non standard function names. It does not change old names, therefore it's impossible to resolve issue. This is the reason why I'm proposing while I like scalar object, use of namespace, etc. Again, you're contradicting yourself here - you can't say that your mission is to change the old names, rather than offer an alternative, but then also say that the old names will stay around forever. If both names exist, that's exactly what you've created - an alternative.I think there is big difference between new API and alias.
Alias is just a copy, new API works differently.
I agree. One difference is that new API is actually useful to people, 
whereas alias just adds to the confusion.
Regards,
-- 
Rowan Collins 
[IMSoP]
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.Again, you're contradicting yourself here - you can't say that your
mission is to change the old names, rather than offer an alternative,
but then also say that the old names will stay around forever. If both
names exist, that's exactly what you've created - an alternative.If we're going to have an alternative, let's come up with a creative
alternative that actually has an advantage to using it, not a choice
between equally cryptic names like "strripos" vs "str_ripos".Regards,
Exactly. If a PHP 7 dev has the option of:
$s = strripos($s, 'a'); // works in PHP 5+
$s = str_ripos($s, 'a'); // works in PHP 7+
Really, what's the advantage of the latter?  Nothing.  It's an extra 
character to type, limits compatibility, and makes my life no easier. 
It's useless, and will just add to the list of things people make fun of 
PHP for instead of reduce it.
Namespacing it is no better:
$s = str\ripos($s, 'a'); // Still useless 
$s = php\str_ripos($s, 'a'); // Still useless
Instead, compare:
$s = strripos($s, 'a'); // works in PHP 5+
$s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+
Oh now we're talking!  That's more self-documenting, easier to discover, 
makes chaining string manipulations easier to read, solves the 
needle/haystack issue, and reduces cholesterol.
One is worth the effort of doing. The other is simply not.
For subsystems that aren't clear scalars, like streams, those need a 
general overhaul for DX, too.  Again, just doubling the number of 
function names adds nothing to the language but confusion, since both 
versions would have to live for at least the next decade.  Offering a 
substantially better alternative does improve the language.  Don't waste 
your time on marginal not-even-improvements.
--Larry Garfield
Hi Larry,
On Tue, Mar 3, 2015 at 8:02 AM, Larry Garfield larry@garfieldtech.com 
wrote:
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.Again, you're contradicting yourself here - you can't say that your
mission is to change the old names, rather than offer an alternative,
but then also say that the old names will stay around forever. If both
names exist, that's exactly what you've created - an alternative.If we're going to have an alternative, let's come up with a creative
alternative that actually has an advantage to using it, not a choice
between equally cryptic names like "strripos" vs "str_ripos".Regards,
Exactly. If a PHP 7 dev has the option of:
$s = strripos($s, 'a'); // works in PHP 5+
$s = str_ripos($s, 'a'); // works in PHP 7+
Really, what's the advantage of the latter? Nothing. It's an extra
character to type, limits compatibility, and makes my life no easier. It's
useless, and will just add to the list of things people make fun of PHP for
instead of reduce it.Namespacing it is no better:
$s = str\ripos($s, 'a'); // Still useless
$s = php\str_ripos($s, 'a'); // Still uselessInstead, compare:
$s = strripos($s, 'a'); // works in PHP 5+
$s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+
Oh now we're talking! That's more self-documenting, easier to discover,
makes chaining string manipulations easier to read, solves the
needle/haystack issue, and reduces cholesterol.One is worth the effort of doing. The other is simply not.
For subsystems that aren't clear scalars, like streams, those need a
general overhaul for DX, too. Again, just doubling the number of function
names adds nothing to the language but confusion, since both versions would
have to live for at least the next decade. Offering a substantially better
alternative does improve the language. Don't waste your time on marginal
not-even-improvements.
I would love to have new & clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will 
remain 
without CORDING_STANDARSDS confirmed names almost forever. This is what 
I would like to improve. If you don't care about legacy stuff cleanups, 
please don't 
care. The cleanups will not hurt anything, almost.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
I would love to have new & clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff cleanups,
please don't
care. The cleanups will not hurt anything, almost.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
On 3/2/15 5:19 PM, Rowan Collins wrote:> On 02/03/2015 22:59, Yasuo
I agree. One difference is that new API is actually useful to people,
whereas alias just adds to the confusion.
^^ What Rowan said. "adds to the confusion" is not "will not hurt 
anything, almost".
--Larry Garfield
I would love to have new & clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff cleanups,
please don't
care. The cleanups will not hurt anything, almost.
No ill intentions here, but adding the aliases and, as you propose, 
literally adding hundreds of aliases is actually a mess to me.
What you call "new & clean" is as a shield for effectively introducing 
duplicates. You do not clean up anything that way. You leave a even 
bigger mess behind. By going for your honorable goal of correcting 
things I think you got lost in the woods.
IMHO the only forward is to make sure new/future additions to the 
language adhere to the coding standard or use a smart way (i.e. the 
scalar addition).
- Markus
Hi Markus, Larry and Rowan,
I would love to have new & clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff cleanups,
please don't
care. The cleanups will not hurt anything, almost.No ill intentions here, but adding the aliases and, as you propose,
literally adding hundreds of aliases is actually a mess to me.What you call "new & clean" is as a shield for effectively introducing
duplicates. You do not clean up anything that way. You leave a even
bigger mess behind. By going for your honorable goal of correcting
things I think you got lost in the woods.IMHO the only forward is to make sure new/future additions to the
language adhere to the coding standard or use a smart way (i.e. the
scalar addition).
I think I understand your point very well. 
However, I have an urge impulse to add standard confirmed names 
when I see manual pages like
http://php.net/manual/en/book.gettext.php 
bind_textdomain_codeset — Specify the character encoding in which the 
messages from the DOMAIN message catalog will be returned 
bindtextdomain — Sets the path for a domain 
dcgettext — Overrides the domain for a single lookup 
dcngettext — Plural version of dcgettext 
dgettext — Override the current domain 
dngettext — Plural version of dgettext 
gettext — Lookup a message in the current domain 
ngettext — Plural version of gettext 
textdomain — Sets the default domain
This looks awful... just cannot put up with...
PHP is evolving as a modern language, but these manual pages/functions 
make me feel PHP as a legacy language. I wish I'm alone who feels this way.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Markus, Larry and Rowan,
I would love to have new & clean APIs.
Please think my proposal as legacy API cleanups. Many of candidates will
remain
without CORDING_STANDARSDS confirmed names almost forever. This is what
I would like to improve. If you don't care about legacy stuff cleanups,
please don't
care. The cleanups will not hurt anything, almost.No ill intentions here, but adding the aliases and, as you propose,
literally adding hundreds of aliases is actually a mess to me.What you call "new & clean" is as a shield for effectively introducing
duplicates. You do not clean up anything that way. You leave a even
bigger mess behind. By going for your honorable goal of correcting
things I think you got lost in the woods.IMHO the only forward is to make sure new/future additions to the
language adhere to the coding standard or use a smart way (i.e. the
scalar addition).I think I understand your point very well.
However, I have an urge impulse to add standard confirmed names
when I see manual pages likehttp://php.net/manual/en/book.gettext.php
bind_textdomain_codeset — Specify the character encoding in which the
messages from the DOMAIN message catalog will be returned
bindtextdomain — Sets the path for a domain
dcgettext — Overrides the domain for a single lookup
dcngettext — Plural version of dcgettext
dgettext — Override the current domain
dngettext — Plural version of dgettext
gettext — Lookup a message in the current domain
ngettext — Plural version of gettext
textdomain — Sets the default domainThis looks awful... just cannot put up with...
These come from the underlying libaries. You can type "man dcgettext" or 
"man bind_textdomain_codeset" at your Linux command line and learn a lot 
about how these work. Plus, if you are a C dev, much like strlen(), 
these are simply the names you expect, or at least they are instantly 
recognizable to you. As I normally explain to people, there is vertical 
consistency here, not horizontal consistency.
I understand how people who don't have a background in the underlying 
libraries might wish for a different API and horizontal consistency 
across disparate extensions, but simply adding a bunch of aliases that 
have no basis in anything doesn't help anybody.
-Rasmus
Hi Rasmus,
These come from the underlying libaries. You can type "man dcgettext" or
"man bind_textdomain_codeset" at your Linux command line and learn a lot
about how these work. Plus, if you are a C dev, much likestrlen(),
these are simply the names you expect, or at least they are instantly
recognizable to you. As I normally explain to people, there is vertical
consistency here, not horizontal consistency.I understand how people who don't have a background in the underlying
libraries might wish for a different API and horizontal consistency
across disparate extensions, but simply adding a bunch of aliases that
have no basis in anything doesn't help anybody.
I know where gettext function names come from. 
If we write these legacy modules now, there will be modname_function() only. 
Why couldn't we do it before PHP7?
I proposed the same before PHP5. 
I'll probably do the same before PHP8 if we have legacy names still...
We can live without new names, so it's not too important. I just feel 
somehow PHP being legacy/unmaintained when I see/use legacy 
function names...
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite ->
http://www.gnu.org/software/gettext/manual/gettext.html
-- 
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
Hi Lester,
This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite ->
http://www.gnu.org/software/gettext/manual/gettext.html
I know we used to have had copy of C library names. 
I already explained why it looks awful. It violates coding standard and 
sitting in PHP for more than a decade as it is.
If we leave behind legacy APIs, we may be better obsolete them ;)
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite ->
http://www.gnu.org/software/gettext/manual/gettext.htmlI know we used to have had copy of C library names.
I already explained why it looks awful. It violates coding standard and
sitting in PHP for more than a decade as it is.
You keep mentioning this coding standard like it's the Holy Bible. 
Coding standards are only as useful as the problem they're trying to 
solve, and there can always be justified exceptions to the rule.
I doubt most PHP users look at that list of functions and think "tsk, 
tsk, the PHP devs didn't follow their own coding standards". They might 
think "why are these functions named the way they are?", in which case 
Rasmus has provided the answer, in terms of "vertical consistency" with 
cross-language libraries.
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins rowan.collins@gmail.com 
wrote:
Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite ->
http://www.gnu.org/software/gettext/manual/gettext.htmlI know we used to have had copy of C library names.
I already explained why it looks awful. It violates coding standard and
sitting in PHP for more than a decade as it is.You keep mentioning this coding standard like it's the Holy Bible. Coding
standards are only as useful as the problem they're trying to solve, and
there can always be justified exceptions to the rule.I doubt most PHP users look at that list of functions and think "tsk, tsk,
the PHP devs didn't follow their own coding standards". They might think
"why are these functions named the way they are?", in which case Rasmus has
provided the answer, in terms of "vertical consistency" with cross-language
libraries.
First of all, I'm not blaming anyone who named functions that violates 
coding standard. 
It was ok name them like this. I would name after under laying library 
functions also.
If the cost of having consistent name is too high (too much cpu/mem/etc) , 
I would not 
propose to add standard confirming names.  What I'm proposing is
"How about maintain legacy APIs to keep up with coding standard and have 
consistent names?"
More or less, we do need maintenance, otherwise phpversion() will remain 
inconsistent 
forever. IMO.
I fully understand your arguments/reasoning, but I fails to see why not 
having aliases to 
have shiny procedural APIs for major version up...
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
More or less, we do need maintenance, otherwise
phpversion()will remain
inconsistent forever. IMO.
Is there any reason why a few peripheral functions like that can't 
simply remain as is? 
ADDING an object with what I will simply describe as 'the new style of 
coding' which provides an alternative API has to be the sensible way 
forward. An object for ini management with a more convenient display 
function in addition to the simple phpversion dump.
I fully understand your arguments/reasoning, but I fails to see why not
having aliases to have shiny procedural APIs for major version up...
Changing the parameter order on the existing function set is not 
practical, but similarly so is changing names which will then produce an 
abysmal mess when searching help files especially when reliance on 
google to provide that function means that we have no control on just 
which version of names are looked up.
The more I look at this from the other side, the better the idea of 
simply adding new format objects to augment the legacy function set 
looks. Certainly leaving things like gd alone and adding a parallel 
'coding style complainant' extension also allows changes to the 
parameter order. Apply the same approach to some of the other extensions 
and at some point in the future we can drop legacy versions ... although 
I suspect that a legacy build will still have a place for some time to 
come.
The piece of the jigsaw I am missing is at which point does it become 
better to create a new extension for a complex object rather than simply 
writing a set of PHP classes?
-- 
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
The piece of the jigsaw I am missing is at which point does it become
better to create a new extension for a complex object rather than
simply
writing a set of PHP classes?
A good question, wrappers can achieve a lot here. An extension has two key benefits that I can think of: performance (indirection through userland code will always be slower, and for frequent operations like string and array handling, it could add up to something significant) and convenience (thanks to Composer, dependency management is pretty simple, but nothing beats functionality built right into the language distribution).
Regards,
Rowan Collins 
[IMSoP]
The piece of the jigsaw I am missing is at which point does it become
better to create a new extension for a complex object rather than
simply
writing a set of PHP classes?A good question, wrappers can achieve a lot here. An extension has two
key benefits that I can think of: performance (indirection through userland
code will always be slower, and for frequent operations like string and
array handling, it could add up to something significant) and convenience
(thanks to Composer, dependency management is pretty simple, but nothing
beats functionality built right into the language distribution).
For a php developer point of view, for someone not knowing c or php 
internals APIs, I highly recommend https://github.com/phalcon/zephir
For a php developer point of view, for someone not knowing c or php
internals APIs, I highly recommend https://github.com/phalcon/zephir
Yasuo is pushing function names on the basis of following the coding 
standard, but again these secondary tools muddy the waters. Zephir 
allows // comments, something which the PHP guide lines avoid for cross 
compiler reasons, so if that is a real problem, the Zephir code may not 
be usable upstream?
It would be helpful if there was at least some consistency to the guide 
lines that we work to rather than having to change rule sets depending 
on where we are in the tool chain.
-- 
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
Hi Rowan,
On Tue, Mar 3, 2015 at 7:13 PM, Rowan Collins rowan.collins@gmail.com
wrote:Yasuo Ohgaki wrote on 03/03/2015 04:01:
Hi Lester,
On Tue, Mar 3, 2015 at 9:19 AM, Lester Caine lester@lsces.co.uk
wrote:This looks awful... just cannot put up with...
Rasmus has already answered, but are you prposing to rewrite ->
http://www.gnu.org/software/gettext/manual/gettext.htmlI know we used to have had copy of C library names.
I already explained why it looks awful. It violates coding standard
and
sitting in PHP for more than a decade as it is.You keep mentioning this coding standard like it's the Holy Bible.
Coding
standards are only as useful as the problem they're trying to solve,
and
there can always be justified exceptions to the rule.I doubt most PHP users look at that list of functions and think "tsk,
tsk,
the PHP devs didn't follow their own coding standards". They might
think
"why are these functions named the way they are?", in which case
Rasmus has
provided the answer, in terms of "vertical consistency" with
cross-language
libraries.First of all, I'm not blaming anyone who named functions that violates
coding standard.
It was ok name them like this. I would name after under laying library
functions also.If the cost of having consistent name is too high (too much
cpu/mem/etc) ,
You are measuring the wrong cost. The cost of adding new names is to people writing code:
- additional confusion for new users about why everything has two names and which they should use
- extra effort for new developers to learn the new names, even if they only read them in other people's code (it slows me down every time I see sizeof()and have to remember it's just an alias ofcount())
- awkward decision for project leaders: use the old names for familiarity and compatibility with older versions, or the new ones because they're arguably better names
- if an existing project does choose the new names, the overhead of converting all the existing code, with the risk of bugs introduced by incorrect automation, noise in commit logs, merge conflicts, etc
- if a project needs to run on PHP 5, the vigilance required to avoid accidentally using the new names when developing on PHP 7
That's not an exhaustive list, and some of these aren't huge costs, but collectively they outweigh the benefit of a slightly more consistent set of names for things.
This is why a more radical change - an OO-style API for scalars and basic modules, a fundamentally new set of functions which fulfil a specific need, etc - has the potential for acceptance, and this proposal does not. The costs are mostly fixed, so we need to increase the benefits to outweigh them.
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
You are measuring the wrong cost. The cost of adding new names is to
people writing code:
- additional confusion for new users about why everything has two names
and which they should use- extra effort for new developers to learn the new names, even if they
only read them in other people's code (it slows me down every time I see
sizeof()and have to remember it's just an alias ofcount())- awkward decision for project leaders: use the old names for familiarity
and compatibility with older versions, or the new ones because they're
arguably better names- if an existing project does choose the new names, the overhead of
converting all the existing code, with the risk of bugs introduced by
incorrect automation, noise in commit logs, merge conflicts, etc- if a project needs to run on PHP 5, the vigilance required to avoid
accidentally using the new names when developing on PHP 7That's not an exhaustive list, and some of these aren't huge costs, but
collectively they outweigh the benefit of a slightly more consistent set of
names for things.This is why a more radical change - an OO-style API for scalars and basic
modules, a fundamentally new set of functions which fulfil a specific need,
etc - has the potential for acceptance, and this proposal does not. The
costs are mostly fixed, so we need to increase the benefits to outweigh
them.
This is fair discussions. We should care these also. I agree these costs 
exist 
and shouldn't ignored.
I have different point of views. It's long term view or new user point of 
view. 
For me, it outweighs costs you've mentioned.
Whether we like it or not, people evaluate languages by matrix like
                         PHP          Ruby            Python
OO support            5               5                  5 
Flexible syntax       3               5                  5 
AOP support          3               3                  3 
DbC                       1              2                  2 
API consistency     1               3                  3 
API richness          4               4                  4 
3rd Party Libs        4               4                  4 
Performance          4               3                  3 
Security                1               4                   4 
Type Safety           1               4                   3
Although this is rough evaluation by me, people would have somewhat similar 
matrix.
API consistency 1 3 3
The reasons why people evaluate PHP like this are
- PHP has API inconsistency even for most basic APIs like phpversion(),
 htmlspecialchars(), etc
- Even bundled modules have non standard function names.
- API parameter ordering is inconsistent.
- Return type for errors are inconsistent. e.g. Wrong number of param 
 returns NULL, while others returnFALSEmostly.
- Some basic internal classes do not raise exception for instantiation 
 failure.
- and so on.
I'm not saying Ruby's APIs are organized very well. For example, user has 
to search 
around proper API even for URI escape provided by various modules. 
Therefore, I 
evaluate it as 3.
Having this kind of evaluation matrix is not good for PHP in the long run. 
IMHO.
BTW,
Security 1 4 4
I evaluate like this because PHP is to weak against fatal security breach. 
i.e. Script Inclusions. 
You'll see my view and the reason why I focus in some area strongly from 
the matrix. Although 
I didn't participate scalar type hint RFC discussion much, I cannot wait to 
have StrictSTH also.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Your evaluation is pretty anecdotal. I agree with some points but you need 
some solid evidence if you are going to rate these languages. Also do you 
have a list of all the functions you would like to rename or is this a 
sweeping lets just change everything so it matches and deprecate all the 
old stuff. Your matrix is a very weak push to do so. If you want to make 
these changes it would be better to choose a select set such as the array 
functions and try and push that through or see what that change might look 
like and if it's really beneficial to userland.
Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins rowan.collins@gmail.com
wrote:You are measuring the wrong cost. The cost of adding new names is to
people writing code:
- additional confusion for new users about why everything has two names
and which they should use- extra effort for new developers to learn the new names, even if they
only read them in other people's code (it slows me down every time I see
sizeof()and have to remember it's just an alias ofcount())- awkward decision for project leaders: use the old names for familiarity
and compatibility with older versions, or the new ones because they're
arguably better names- if an existing project does choose the new names, the overhead of
converting all the existing code, with the risk of bugs introduced by
incorrect automation, noise in commit logs, merge conflicts, etc- if a project needs to run on PHP 5, the vigilance required to avoid
accidentally using the new names when developing on PHP 7That's not an exhaustive list, and some of these aren't huge costs, but
collectively they outweigh the benefit of a slightly more consistent set
of
names for things.This is why a more radical change - an OO-style API for scalars and basic
modules, a fundamentally new set of functions which fulfil a specific
need,
etc - has the potential for acceptance, and this proposal does not. The
costs are mostly fixed, so we need to increase the benefits to outweigh
them.This is fair discussions. We should care these also. I agree these costs
exist
and shouldn't ignored.I have different point of views. It's long term view or new user point of
view.
For me, it outweighs costs you've mentioned.Whether we like it or not, people evaluate languages by matrix like
PHP Ruby PythonOO support 5 5 5
Flexible syntax 3 5 5
AOP support 3 3 3
DbC 1 2 2
API consistency 1 3 3
API richness 4 4 4
3rd Party Libs 4 4 4
Performance 4 3 3
Security 1 4 4
Type Safety 1 4 3Although this is rough evaluation by me, people would have somewhat similar
matrix.API consistency 1 3 3
The reasons why people evaluate PHP like this are
- PHP has API inconsistency even for most basic APIs like
phpversion(),
htmlspecialchars(), etc- Even bundled modules have non standard function names.
- API parameter ordering is inconsistent.
- Return type for errors are inconsistent. e.g. Wrong number of param
returns NULL, while others returnFALSEmostly.- Some basic internal classes do not raise exception for instantiation
failure.- and so on.
I'm not saying Ruby's APIs are organized very well. For example, user has
to search
around proper API even for URI escape provided by various modules.
Therefore, I
evaluate it as 3.Having this kind of evaluation matrix is not good for PHP in the long run.
IMHO.BTW,
Security 1 4 4
I evaluate like this because PHP is to weak against fatal security breach.
i.e. Script Inclusions.
You'll see my view and the reason why I focus in some area strongly from
the matrix. Although
I didn't participate scalar type hint RFC discussion much, I cannot wait to
have StrictSTH also.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett michaeljs1990@gmail.com 
wrote:
Your evaluation is pretty anecdotal. I agree with some points but you need
some solid evidence if you are going to rate these languages. Also do you
have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all the
old stuff. Your matrix is a very weak push to do so. If you want to make
these changes it would be better to choose a select set such as the array
functions and try and push that through or see what that change might look
like and if it's really beneficial to userland.
I agree that my evaluation is subjective. For example, I rate PHP has "1" 
security only 
because PHP is very weak against script/file inclusions because it's fatal 
and other 
languages apps do not have script/file inclusions as PHP apps do. Others 
might 
rate "2" or even "3" because it is too easy to fix it even if incident is 
fatal. 
(Security should be evaluated by "how difficult to make mistakes", not "how 
easy to 
fix mistakes" generally. IMHO)
I made list of rename candidates 
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed 
If you have suggestions, I appreciate!
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
(Security should be evaluated by "how difficult to make mistakes", not
"how easy to
fix mistakes" generally. IMHO)
And the consequence of the security breach, of course.
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
So i find this kind of odd since you use err every other place in bz. but 
this is a minor nitpick.
- bz_error → bzerror
- bz_error_str → bzerrstr
Overall I fell this change would be nice for new people coming to PHP and 
alienate some long time users. We also run the risk at this point that 
Python has run into with 2 vs 3 which has enough minor changes that no one 
is moving over and just ended up with people supporting 2 longer and not 
moving to 3. I feel we can learn from their mistakes. I would vote yes for 
this but I see why others would not.
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett michaeljs1990@gmail.com
wrote:Your evaluation is pretty anecdotal. I agree with some points but you
need some solid evidence if you are going to rate these languages. Also do
you have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all the
old stuff. Your matrix is a very weak push to do so. If you want to make
these changes it would be better to choose a select set such as the array
functions and try and push that through or see what that change might look
like and if it's really beneficial to userland.I agree that my evaluation is subjective. For example, I rate PHP has "1"
security only
because PHP is very weak against script/file inclusions because it's fatal
and other
languages apps do not have script/file inclusions as PHP apps do. Others
might
rate "2" or even "3" because it is too easy to fix it even if incident is
fatal.
(Security should be evaluated by "how difficult to make mistakes", not
"how easy to
fix mistakes" generally. IMHO)I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Michael,
On Wed, Mar 4, 2015 at 12:58 PM, Michael Schuett michaeljs1990@gmail.com 
wrote:
So i find this kind of odd since you use err every other place in bz. but
this is a minor nitpick.
- bz_error → bzerror
- bz_error_str → bzerrstr
Overall I fell this change would be nice for new people coming to PHP and
alienate some long time users. We also run the risk at this point that
Python has run into with 2 vs 3 which has enough minor changes that no one
is moving over and just ended up with people supporting 2 longer and not
moving to 3. I feel we can learn from their mistakes. I would vote yes for
this but I see why others would not.
I'm glad there is one person in favor at least.
I've looked manual more carefully, "errstr" and "errno" is used as 
abbreviated words 
I've updated RFC so that "errstr" and "errno" are words.
https://wiki.php.net/rfc/consistent_function_names
I also added more aliases in "Open Issue". I didn't add them since I felt 
these 
are a little too destructive.
Comments and suggestions are appreciated!
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!
Taking the starting point ... the coding standard for writing C code for 
PHP ... personally I would love if the PHP code area followed all of the 
rules in the C set. My own particular grip is with using tabs internally 
in the C code, but spaces in the PHP code. The very reason that PSR is 
another inconsistency. So we follow C rules for C code and PSR rules for 
PHP. Or not ... I will always use tabs across all code bases, but the 
other point here is that PSR demands camelCase rather than adding 
underscores and many of the new libraries have been added following that 
format rather than the C rules.
So even replacing the whole structure of internal names, they will be 
inconsistent with external naming 'rules'. The coding standards 
themselves are inconsistent :(
If we are looking at the C codespace, then as has already been said we 
are using C library names in a large majority of cases. So programmers 
who are switching between C and PHP codespace either need to rebuild all 
of the C libraries using the new names, or live with that inconsistency?
I am slowly coming around to the thought that since how I would prefer 
to work is not going to be provided by PHP then creating my own versions 
of some extensions is going to be the right way forward, so I will 
perhaps be working more in 'C' space than in 'PHP' space. This is partly 
because of the growing uncertainty about handling SQL compliant types in 
PHP, and the increasing need to work out how to add back the limit 
checks provided naturally by 32bit processor builds. There are a lot 
more important things than introducing what I view as yet another layer 
of inconsistency when for example, the whole string management area 
needs to be augmented with a proper object based structure where the 
str_ becomes redundant? mbstring should also become redundant in that 
rework.
As I have already said, the GD library is just a wrapper around the 
underlying libgd C package, and while it is now maintained by Pierre 
under the umbrella of PHP, it is used in other languages so creating a 
new wrapper for PHP without regard for it's C and other interfaces is 
again introducing more inconsistencies.
While http has been rejected for bundling, it is another example of not 
following the C coding standard ...
-- 
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
I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!Taking the starting point ... the coding standard for writing C code for
PHP ... personally I would love if the PHP code area followed all of the
rules in the C set. My own particular grip is with using tabs internally
in the C code, but spaces in the PHP code. The very reason that PSR is
another inconsistency. So we follow C rules for C code and PSR rules for
PHP. Or not ... I will always use tabs across all code bases, but the
other point here is that PSR demands camelCase rather than adding
underscores and many of the new libraries have been added following that
format rather than the C rules.So even replacing the whole structure of internal names, they will be
inconsistent with external naming 'rules'. The coding standards
themselves are inconsistent :(If we are looking at the C codespace, then as has already been said we
are using C library names in a large majority of cases. So programmers
who are switching between C and PHP codespace either need to rebuild all
of the C libraries using the new names, or live with that inconsistency?I am slowly coming around to the thought that since how I would prefer
to work is not going to be provided by PHP then creating my own versions
of some extensions is going to be the right way forward, so I will
perhaps be working more in 'C' space than in 'PHP' space. This is partly
because of the growing uncertainty about handling SQL compliant types in
PHP, and the increasing need to work out how to add back the limit
checks provided naturally by 32bit processor builds. There are a lot
more important things than introducing what I view as yet another layer
of inconsistency when for example, the whole string management area
needs to be augmented with a proper object based structure where the
str_ becomes redundant? mbstring should also become redundant in that
rework.As I have already said, the GD library is just a wrapper around the
underlying libgd C package, and while it is now maintained by Pierre
under the umbrella of PHP, it is used in other languages so creating a
new wrapper for PHP without regard for it's C and other interfaces is
again introducing more inconsistencies.While http has been rejected for bundling, it is another example of not
following the C coding standard …
Lester, please stop posting walls of unrelated text. You’re totally off track. If we’re talking about coding standards, we’re not talking about PSR, but http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS
Regards, 
Mike
While http has been rejected for bundling, it is another example of not
following the C coding standard …
Lester, please stop posting walls of unrelated text. You’re totally off track. If we’re talking about coding standards, we’re not talking about PSR, but http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS http://lxr.php.net/xref/PHP_TRUNK/CODING_STANDARDS
In that case the rules should be applied to everything that is added to 
PHP rather than being selective?
The points still apply ... Personally I have no interest in PSR and 
would prefer that PHP_TRUNK/CODING_STANDARDS was a rule that was 
followed before extensions like http were even debated, but the 
inconsistencies that are being objected to are to address complaints in 
'PHP' space rather than 'C' space, and it has already been accepted that 
different rules apply there anyway :( I got chewed out last time I 
pointed out that PHP_TRUNK/CODING_STANDARDS is not being followed in 
'PHP' space ...
-- 
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
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett michaeljs1990@gmail.com
wrote:Your evaluation is pretty anecdotal. I agree with some points but you need
some solid evidence if you are going to rate these languages. Also do you
have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all the
old stuff. Your matrix is a very weak push to do so. If you want to make
these changes it would be better to choose a select set such as the array
functions and try and push that through or see what that change might look
like and if it's really beneficial to userland.I agree that my evaluation is subjective. For example, I rate PHP has "1"
security only
because PHP is very weak against script/file inclusions because it's fatal
and other
languages apps do not have script/file inclusions as PHP apps do. Others
might
rate "2" or even "3" because it is too easy to fix it even if incident is
fatal.
(Security should be evaluated by "how difficult to make mistakes", not "how
easy to
fix mistakes" generally. IMHO)I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed
If you have suggestions, I appreciate!
Yasuo, please stop. This isn't going to happen. Changing strlen() to 
str_len() is just ridiculous.
-Rasmus
... well that's a constructive way of going about it. I don't think Yasuo 
did anything harmful or rude in making his proposal. Regardless of how 
realistic the idea may be, I don't think its ever appropriate or 
constructive to tell someone to simply "stop" because something "is just 
ridiculous".
Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett <
michaeljs1990@gmail.com>
wrote:Your evaluation is pretty anecdotal. I agree with some points but you
need
some solid evidence if you are going to rate these languages. Also do
you
have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all the
old stuff. Your matrix is a very weak push to do so. If you want to make
these changes it would be better to choose a select set such as the
array
functions and try and push that through or see what that change might
look
like and if it's really beneficial to userland.I agree that my evaluation is subjective. For example, I rate PHP has "1"
security only
because PHP is very weak against script/file inclusions because it's
fatal
and other
languages apps do not have script/file inclusions as PHP apps do. Others
might
rate "2" or even "3" because it is too easy to fix it even if incident is
fatal.
(Security should be evaluated by "how difficult to make mistakes", not
"how
easy to
fix mistakes" generally. IMHO)I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#
list_of_functions_to_be_renamed
If you have suggestions, I appreciate!Yasuo, please stop. This isn't going to happen. Changing
strlen()to
str_len() is just ridiculous.-Rasmus
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2 
majors, deprecate the inconsistent one in the following and remove later.
... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply "stop" because something "is just
ridiculous".Hi Michael,
On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett <
michaeljs1990@gmail.com>
wrote:Your evaluation is pretty anecdotal. I agree with some points but you
need
some solid evidence if you are going to rate these languages. Also do
you
have a list of all the functions you would like to rename or is this a
sweeping lets just change everything so it matches and deprecate all
the
old stuff. Your matrix is a very weak push to do so. If you want to
make
these changes it would be better to choose a select set such as the
array
functions and try and push that through or see what that change might
look
like and if it's really beneficial to userland.I agree that my evaluation is subjective. For example, I rate PHP has
"1"
security only
because PHP is very weak against script/file inclusions because it's
fatal
and other
languages apps do not have script/file inclusions as PHP apps do.
Others
might
rate "2" or even "3" because it is too easy to fix it even if incident
is
fatal.
(Security should be evaluated by "how difficult to make mistakes", not
"how
easy to
fix mistakes" generally. IMHO)I made list of rename candidates
https://wiki.php.net/rfc/consistent_function_names#
list_of_functions_to_be_renamed
If you have suggestions, I appreciate!Yasuo, please stop. This isn't going to happen. Changing
strlen()to
str_len() is just ridiculous.-Rasmus
-- 
Guilherme Blanco 
MSN: guilhermeblanco@hotmail.com 
GTalk: guilhermeblanco 
Toronto - ON/Canada
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.
As far as I am concerned str_len() would be the inconsistent one. Like I 
explained previously, these function names for the most part, aren't 
ones I made up. They come from the underlying libraries and whether you 
personally value that or not, there is an actual reason for their names. 
Many of them are iconic entities on their own, at least to people with 
experience outside of PHP. Terms like "recvfrom", "getenv" and yes, 
"strlen" are well-established names that should not be split up into 
"recv_from", "get_env" and "str_len" due to some sort of arbitrary 
consistency/purity idea any more than I should have my name changed to 
Ras_mus.
As many people have already suggested in this thread, if we are going to 
do something here it has to bring actual value and can't just be a bunch 
of aliases littering the global namespace further.
-Rasmus
Hi Rasmus,
@Rasmus:
I don't see what's the problem of aliasing functions for the next 1-2
majors, deprecate the inconsistent one in the following and remove later.As far as I am concerned str_len() would be the inconsistent one. Like I
explained previously, these function names for the most part, aren't
ones I made up. They come from the underlying libraries and whether you
personally value that or not, there is an actual reason for their names.
Many of them are iconic entities on their own, at least to people with
experience outside of PHP. Terms like "recvfrom", "getenv" and yes,
"strlen" are well-established names that should not be split up into
"recv_from", "get_env" and "str_len" due to some sort of arbitrary
consistency/purity idea any more than I should have my name changed to
Ras_mus.As many people have already suggested in this thread, if we are going to
do something here it has to bring actual value and can't just be a bunch
of aliases littering the global namespace further.
I have mixed feeling for well established names indeed. 
These function names are debatable. Latest RFC leaves fopen()/fread()/etc 
as it is now, for example.
https://wiki.php.net/rfc/consistent_function_names#file_related_functions
Personally, I don't mind to keep current names for strlen()/etc. 
You don't mind at all to have php_version()/etc probably. It's possible to 
have separate vote for names that are debatable or even keep current 
names without vote.
If you could provide list of debatable names, I'll have separate votes for 
them 
or keep current names without vote.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Rasmus,
On Thu, Mar 5, 2015 at 1:46 AM, Rasmus Lerdorf <rasmus@lerdorf.com
mailto:rasmus@lerdorf.com> wrote:On 03/04/2015 08:26 AM, guilhermeblanco@gmail.com <mailto:guilhermeblanco@gmail.com> wrote: > @Rasmus: > > I don't see what's the problem of aliasing functions for the next 1-2 > majors, deprecate the inconsistent one in the following and remove later. As far as I am concerned str_len() would be the inconsistent one. Like I explained previously, these function names for the most part, aren't ones I made up. They come from the underlying libraries and whether you personally value that or not, there is an actual reason for their names. Many of them are iconic entities on their own, at least to people with experience outside of PHP. Terms like "recvfrom", "getenv" and yes, "strlen" are well-established names that should not be split up into "recv_from", "get_env" and "str_len" due to some sort of arbitrary consistency/purity idea any more than I should have my name changed to Ras_mus. As many people have already suggested in this thread, if we are going to do something here it has to bring actual value and can't just be a bunch of aliases littering the global namespace further.I have mixed feeling for well established names indeed.
These function names are debatable. Latest RFC leavesfopen()/fread()/etc
as it is now, for example.https://wiki.php.net/rfc/consistent_function_names#file_related_functions
Personally, I don't mind to keep current names for
strlen()/etc.
You don't mind at all to have php_version()/etc probably. It's possible to
have separate vote for names that are debatable or even keep current
names without vote.If you could provide list of debatable names, I'll have separate votes
for them
or keep current names without vote.
Every function name defined by IEEE Std 1003.1 along with the arguments 
and argument order would be on that list. When we have procedural 
functions that are either thin wrappers around or otherwise behave 
identically to an IEEE 1003.1 defined function, then the name and 
arguments currently match that specification quite well. Any deviation 
should have a really really good reason.
You can find the full list here:
http://pubs.opengroup.org/onlinepubs/9699919799/idx/is.html
Click on the letters at the top for functions starting with the other 
letters.
-Rasmus
Hi Rasmus,
Every function name defined by IEEE Std 1003.1 along with the arguments
and argument order would be on that list. When we have procedural
functions that are either thin wrappers around or otherwise behave
identically to an IEEE 1003.1 defined function, then the name and
arguments currently match that specification quite well. Any deviation
should have a really really good reason.You can find the full list here:
I like the idea to be IEEE 1003.1 compliant. I'm used to these name too. 
If anyone don't mind, I would like to extend scope of the RFC to have 
both PHP and IEEE names and document them.
For example, ctype extension has "ctype_" prefix. It replaces "is" to 
"ctype_". 
we may have "isalpha" alias as IEEE compliant name. There are many 
IEEE confirmed names already. Only small adjustments are needed.
Document may look like
http://php.net/manual/en/function.ctype-alnum.php
ctype_alnum 
Aliases
- isalnum (IEEE 1003.1)   <- There is no "isalnum" defined in PHP 
 currently.
(PHP 4 >= 4.0.4, PHP 5) 
ctype_alnum — Check for alphanumeric character(s)
Description ¶
bool ctype_alnum ( string $text ) 
Checks if all of the characters in the provided string, text, are 
alphanumeric.
Parameters ¶
text 
The tested string.
Return Values ¶
Returns TRUE if every character in text is either a letter or a digit, 
FALSE otherwise.
The same could be done for new names. 
Manual pages for localtime()/mktime()/etc would look a lot nicer. 
I hope there will be more favored developers with the RFC. Since I'm going 
to 
update manual to have alias search feature, developers used to POSIX can 
find 
PHP function name easily. If they would like to use POSIX name, they can use 
it also. Nobody will try to remove POSIX names in the future, I suppose.
In short, I would like to propose to have both PHP and IEEE names as 
officially 
valid names. Do you like this proposal?
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki, Sent: Thursday, March 05, 2015 7:21 AM
For example, ctype extension has "ctype_" prefix. It replaces
"is" to "ctype_".
we may have "isalpha" alias as IEEE compliant name. There are many
IEEE confirmed names already. Only small adjustments are needed.
Changing ctype_alpha to isalpha would be inconsistent with is_numeric.
Best regards
Hi Christian,
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 7:21 AMFor example, ctype extension has "ctype_" prefix. It replaces
"is" to "ctype_".
we may have "isalpha" alias as IEEE compliant name. There are many
IEEE confirmed names already. Only small adjustments are needed.Changing ctype_alpha to isalpha would be inconsistent with is_numeric.
I'm not going to change ctype_alpha to isalpha, but add IEEE complied name 
alias. So the manual page would have ctype_alpha as the main function, 
isalpha as IEEE complied alias.
BTW, I'm going to get rid of aliased/deprecated function listing. So aliases 
and deprecated functions will not be listed, but only searchable.
For example, http://php.net/manual/en/book.ctype.php will not be changed. 
http://php.net/manual/en/book.classobj.php will not list deprecated 
call_user_method_array and call_user_method (or listed separately)
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki, Sent: Thursday, March 05, 2015 9:45 AM
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo Ohgaki, Sent: Thursday, March 05, 2015 > 7:21 AM
For example, ctype extension has "ctype_" prefix. It replaces
"is" to "ctype_".
we may have "isalpha" alias as IEEE compliant name. There are many
IEEE confirmed names already. Only small adjustments are needed.Changing ctype_alpha to isalpha would be inconsistent with is_numeric.
I'm not going to change ctype_alpha to isalpha, but add IEEE complied name
alias. So the manual page would have ctype_alpha as the main function,
isalpha as IEEE complied alias.
Hi Yasuo,
I am not sure if you understood me correctly. If you add the alias isalpha, there will be people who will complain about new inconsistences, because there will be isalpha and is_numeric. Function names starting with "is", having an underscore and some having no underscore.
I do not think that this mix will lead to less complains by developers.
Christian
Hi Christian,
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 9:45 AMOn Thu, Mar 5, 2015 at 4:34 PM, Christian Stoller stoller@leonex.de
wrote:
From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 > 7:21 AMFor example, ctype extension has "ctype_" prefix. It replaces
"is" to "ctype_".
we may have "isalpha" alias as IEEE compliant name. There are many
IEEE confirmed names already. Only small adjustments are needed.Changing ctype_alpha to isalpha would be inconsistent with is_numeric.
I'm not going to change ctype_alpha to isalpha, but add IEEE complied
name
alias. So the manual page would have ctype_alpha as the main function,
isalpha as IEEE complied alias.Hi Yasuo,
I am not sure if you understood me correctly. If you add the alias
isalpha, there will be people who will complain about new inconsistences,
because there will beisalphaandis_numeric. Function names starting
with "is", having an underscore and some having no underscore.I do not think that this mix will lead to less complains by developers.
Your point may be true.
AFAIK, developers are complaining about
- procedural functions having current and old naming conventions
- string and array functions has different parameter order for $needle and 
 $subject
POSIX compliant names may be added as alias for IEEE 1003.1 compliance. 
I'll indicate those functions are comply IEEE 1003.1 standard convention 
mostly. 
PHP is not C, so it cannot comply fully, but PHP can comply mostly. For 
developers 
know IEEE 1003.1 can use these functions assuming it works as IEEE 1003.1 
function mostly. Most developers will not complain to have IEEE 1003.1 
complied 
aliases, I suppose.
While I think IEEE complied names are useful, others may not. 
I'll have vote option for this.
I appreciate feedback!
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
The same could be done for new names.
Manual pages forlocaltime()/mktime()/etc would look a lot nicer.
I hope there will be more favored developers with the RFC. Since I'm
going to
update manual to have alias search feature, developers used to POSIX can
find
PHP function name easily. If they would like to use POSIX name, they can use
it also. Nobody will try to remove POSIX names in the future, I suppose.In short, I would like to propose to have both PHP and IEEE names as
officially
valid names. Do you like this proposal?
Nope, I don't. PHP is over 20 years old at this point and the PHP names 
for the functions are one and the same as the IEEE names. I see 
absolutely no reason to create a new class of "PHP" names.
-Rasmus
Hi Rasmus,
The same could be done for new names.
Manual pages forlocaltime()/mktime()/etc would look a lot nicer.
I hope there will be more favored developers with the RFC. Since I'm
going to
update manual to have alias search feature, developers used to POSIX can
find
PHP function name easily. If they would like to use POSIX name, they can
use
it also. Nobody will try to remove POSIX names in the future, I suppose.In short, I would like to propose to have both PHP and IEEE names as
officially
valid names. Do you like this proposal?Nope, I don't. PHP is over 20 years old at this point and the PHP names
for the functions are one and the same as the IEEE names. I see
absolutely no reason to create a new class of "PHP" names.
Since we have both violations, IEEE and PHP, having both would 
be possible resolution. I don't like to be somewhere between. 
Some functions confirm, but others don't, isn't nice to have. If we 
comply, complying as much as possible is better. IMHO.
Anyway, if you would like to keep only mktime()/nl_langinfo()/etc without 
PHP coding standard names. I'll make this an option.
What about adding IEEE confirmed aliases like isalpha()? 
Would you like to have these?
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Yasuo, please stop. This isn't going to happen. Changing
strlen()to
str_len() is just ridiculous. -Rasmus
Trevor Suarez wrote on 04/03/2015 15:33:
... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply "stop" because something "is just
ridiculous".
It's a bit of a crotchety answer, yes, but at this stage pretty much 
everything has already been said (a) in this thread, and (b) in similar 
threads every few months going back as long as I've been subscribed to 
the list, and undoubtedly for a long time before that.
If Rasmus has seen this conversation several times a year for the last 
20 years, with the same conclusions every time, I don't blame him for 
being a bit tired of it.
There have been some alternatives suggested - come up with a change with 
a compelling advantage rather than tweaking the names - so if you're 
looking for something constructive, help move those ideas forward, 
rather than flogging the dead horse.
Regards,
Rowan Collins 
[IMSoP]
so if you're looking for something constructive, help move those ideas
forward, rather than flogging the dead horse.
The extensive changes documented in this RFC are well over the top, but 
a much better approach would be to identify blocks which do allow for 
alternative approaches. It would perhaps make sense to tidy up the 
coding guidelines to reflect that a substantial section of the names 
used simply follow the relevant standard already?
Is http://pubs.opengroup.org/onlinepubs/9699919799/ a suitable reference 
to use in defence of the existing names amongst other things? Or is 
there another standard people uuuse in addition to the man pages?
-- 
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
Yasuo, please stop. This isn't going to happen. Changing
strlen()to str_len() is just ridiculous. -RasmusTrevor Suarez wrote on 04/03/2015 15:33:
... well that's a constructive way of going about it. I don't think Yasuo
did anything harmful or rude in making his proposal. Regardless of how
realistic the idea may be, I don't think its ever appropriate or
constructive to tell someone to simply "stop" because something "is just
ridiculous".It's a bit of a crotchety answer, yes, but at this stage pretty much everything has already been said (a) in this thread, and (b) in similar threads
every few months going back as long as I've been subscribed to the list, and undoubtedly for a long time before that.If Rasmus has seen this conversation several times a year for the last 20 years, with the same conclusions every time, I don't blame him for being a
bit tired of it.There have been some alternatives suggested - come up with a change with a compelling advantage rather than tweaking the names - so if you're looking
for something constructive, help move those ideas forward, rather than flogging the dead horse.Regards,
See #6 at https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process
Chris
Hi Rowan,
On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins rowan.collins@gmail.com
wrote:You are measuring the wrong cost. The cost of adding new names is to
people writing code:
- additional confusion for new users about why everything has two
names
and which they should use- extra effort for new developers to learn the new names, even if
they
only read them in other people's code (it slows me down every time I
see
sizeof()and have to remember it's just an alias ofcount())- awkward decision for project leaders: use the old names for
familiarity
and compatibility with older versions, or the new ones because
they're
arguably better names- if an existing project does choose the new names, the overhead of
converting all the existing code, with the risk of bugs introduced by
incorrect automation, noise in commit logs, merge conflicts, etc- if a project needs to run on PHP 5, the vigilance required to avoid
accidentally using the new names when developing on PHP 7That's not an exhaustive list, and some of these aren't huge costs,
but
collectively they outweigh the benefit of a slightly more consistent
set of
names for things.This is why a more radical change - an OO-style API for scalars and
basic
modules, a fundamentally new set of functions which fulfil a specific
need,
etc - has the potential for acceptance, and this proposal does not.
The
costs are mostly fixed, so we need to increase the benefits to
outweigh
them.This is fair discussions. We should care these also. I agree these
costs
exist
and shouldn't ignored.I have different point of views. It's long term view or new user point
of
view.
For me, it outweighs costs you've mentioned.
Several of the costs I listed are for new users, and several will continue indefinitely if we don't remove the old names, and are therefore long term.
Could you be more explicit in the benefits you see? I.e. day to day, how will users lives be better with these new names?
- PHP has API inconsistency even for most basic APIs like
phpversion(),
htmlspecialchars(), etc- Even bundled modules have non standard function names.
- API parameter ordering is inconsistent.
- Return type for errors are inconsistent. e.g. Wrong number of param
returns NULL, while others returnFALSEmostly.
For me, argument order and return inconsistency is a much worse problem than name inconsistency. Unfortunately, it's also harder to fix without massive BC breaks. Again, this leads to the conclusion of replacing the entire legacy API, rather than trying to patch over it.
I also think having two names for every function will count as a negative to the kind of people who write these matrixes, and the fact that it was done to fix a previous negative won't change that.
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Wed, Mar 4, 2015 at 6:16 PM, Rowan Collins rowan.collins@gmail.com 
wrote:
Several of the costs I listed are for new users, and several will continue
indefinitely if we don't remove the old names, and are therefore long term.Could you be more explicit in the benefits you see? I.e. day to day, how
will users lives be better with these new names?
When I start programming with PHP at 2000, I remember that I was confused 
function naming convention a lot. I hope that current new users do not have 
such confusions, but they probably feel inconsistent name as issue because 
it does not look right. Even if IDEs suggest "right" names, I just feel 
wrong. 
I guess there are not few people feel same way.
People who prefer Ruby likes it because it's not only have shorthand 
notations 
but it is predictable in many ways. In PHP7, we finally have 
uniform(predictable) 
evaluation order! predictable foreach! why not predictable function names?
Since PHP does not have predictable(consistent) names even for most basic 
functions, function names are not predictable. It makes harder for new PHP 
developers to get used to.
As you mentioned, the changes may cause more confusions in short term. 
I agree with this. Change causes confusions always more or less... 
For me, it is a choice whether
- we'll have naming confusion forever 
 or
- we'll fix it even if there are some confusion in short term resolve it 
 in the long run.
- PHP has API inconsistency even for most basic APIs like
phpversion(),htmlspecialchars(), etc
- Even bundled modules have non standard function names.
- API parameter ordering is inconsistent.
- Return type for errors are inconsistent. e.g. Wrong number of param
returns NULL, while others returnFALSEmostly.For me, argument order and return inconsistency is a much worse problem
than name inconsistency. Unfortunately, it's also harder to fix without
massive BC breaks. Again, this leads to the conclusion of replacing the
entire legacy API, rather than trying to patch over it.
I agree fully. I wish we have FALSE for wrong number of parameters. 
We should try to provide nicer and consistent new APIs.
However, old API will be kept regardless of new APIs because we care 
compatibility. We still have "is_writeable()" (This is typo function) alias 
for compatibility, for example.
I'll try to modify document system so that it can handle aliases more 
nicely. e.g. Do not list aliases in function list, but document them in 
referred function. htmlspecialchars() is documented in html_escape() 
and make search system find html_escape() by searching "htmlspecialchars".
If this is done, we don't have many aliases listed in manual page.
I also think having two names for every function will count as a negative
to the kind of people who write these matrixes, and the fact that it was
done to fix a previous negative won't change that.
Keeping legacy names is almost the same as keeping "is_writeable()" 
for me... 
I'll try as much as I can, like adjusting manual and search system, so 
that PHP appears to have consistent function names. This would help 
people to reconsider.
We cannot remove all issue at once. We are better to adopt incremental 
improvement, aren't we?
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
We cannot remove all issue at once. We are better to adopt incremental
improvement, aren't we?
I think this, more than anything else, is where I disagree (having been persuaded by arguments in previous discussions). Incremental improvements mean having the cost of change multiple times, and the benefit just a promise for the future. It's like living in a building site while rebuilding your house - sometimes necessary, but not what you'd choose.
If we have two names with no other fixes now, then later a third name, or some magic flag, which fixes the argument order and error behaviour, then go through and tidy up, we'll end up with a whole flow chart of "if you need to support version X, use Y; if you find a tutorial using A, replace with B..."
Some such change is inevitable - a huge number of tutorials became out of date when ext/mysql was deprecated, for instance - but it's not something to do "little and often" just to make things "a little bit better".
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
We cannot remove all issue at once. We are better to adopt incremental
improvement, aren't we?I think this, more than anything else, is where I disagree (having been
persuaded by arguments in previous discussions). Incremental improvements
mean having the cost of change multiple times, and the benefit just a
promise for the future. It's like living in a building site while
rebuilding your house - sometimes necessary, but not what you'd choose.If we have two names with no other fixes now, then later a third name, or
some magic flag, which fixes the argument order and error behaviour, then
go through and tidy up, we'll end up with a whole flow chart of "if you
need to support version X, use Y; if you find a tutorial using A, replace
with B..."Some such change is inevitable - a huge number of tutorials became out of
date when ext/mysql was deprecated, for instance - but it's not something
to do "little and often" just to make things "a little bit better".
Sounds reasonable. I've updated RFC to note not addressed inconsistencies 
explicitly. 
There may be others.
Some of these may be addressed by this RFC.
https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality
Unaffected PHP Functionality
This RFC only addresses inconsistent names. These are the list of related 
inconsistencies.
- Parameter order inconsistency. This may be addressed by “default 
 namespace” in other RFC.
- Return type inconsistency. Most severe inconsistency is “wrong number 
 of parameters returns NULL”. This may be addressed by “INI switch” in other
 RFC.
- Constant name inconsistency.
- Class and method names. Only “__set_state()” and “create_sid()” methods 
 are addressed.
Future Scope
- Use of namespace to clean up global namespace at all.
- New APIs that replace old APIs.
- Parameter order inconsistency.
- Return type inconsistency.
- Constant name inconsistency.
- Class inconsistency.
Functions return NULL for wrong number of parameters is easy one to fix 
without BC. 
We may have INI switch return FALSE for invalid number of parameters.
return_value_consistency=On/Off  ; Returns FALSE when number of parameter 
is wrong for module functions.
Parameter ordering issue may be addressed also. Instead of having alias, we 
may introduce new functions 
for them. The new function name could be issue, though. If you know good 
list of functions have strange 
parameter ordering, I appreciate it.
Parameter ordering issue could be addressed by "default namespace" that can 
import functions/classes 
to root namespace. This approach requires more work, but it would be 
cleaner than simply having new 
API. I think this issue would be large enough to be a RFC, though...
Do you have particular suggestions?
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins
rowan.collins@gmail.com
wrote:On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:We cannot remove all issue at once. We are better to adopt
incremental
improvement, aren't we?I think this, more than anything else, is where I disagree (having
been
persuaded by arguments in previous discussions). Incremental
improvements
mean having the cost of change multiple times, and the benefit just a
promise for the future. It's like living in a building site while
rebuilding your house - sometimes necessary, but not what you'd
choose.If we have two names with no other fixes now, then later a third
name, or
some magic flag, which fixes the argument order and error behaviour,
then
go through and tidy up, we'll end up with a whole flow chart of "if
you
need to support version X, use Y; if you find a tutorial using A,
replace
with B..."Some such change is inevitable - a huge number of tutorials became
out of
date when ext/mysql was deprecated, for instance - but it's not
something
to do "little and often" just to make things "a little bit better".Sounds reasonable. I've updated RFC to note not addressed
inconsistencies
explicitly.
There may be others.Some of these may be addressed by this RFC.
https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality
Unaffected PHP Functionality
This RFC only addresses inconsistent names. These are the list of
related
inconsistencies.
- Parameter order inconsistency. This may be addressed by “default
namespace” in other RFC.- Return type inconsistency. Most severe inconsistency is “wrong number
of parameters returns NULL”. This may be addressed by “INI switch” in
other
RFC.- Constant name inconsistency.
- Class and method names. Only “__set_state()” and “create_sid()”
methods
are addressed.Future Scope
- Use of namespace to clean up global namespace at all.
- New APIs that replace old APIs.
- Parameter order inconsistency.
- Return type inconsistency.
- Constant name inconsistency.
- Class inconsistency.
Functions return
NULLfor wrong number of parameters is easy one to fix
without BC.
We may have INI switch returnFALSEfor invalid number of parameters.return_value_consistency=On/Off ; Returns
FALSEwhen number of
parameter
is wrong for module functions.Parameter ordering issue may be addressed also. Instead of having
alias, we
may introduce new functions
for them. The new function name could be issue, though. If you know
good
list of functions have strange
parameter ordering, I appreciate it.Parameter ordering issue could be addressed by "default namespace" that
can
import functions/classes
to root namespace. This approach requires more work, but it would be
cleaner than simply having new
API. I think this issue would be large enough to be a RFC, though...Do you have particular suggestions?
You missed my point: doing this but by bit is the worst solution, not the best. One of your suggestions implies that we'll have 3 names for the same function: the one that's existed for 20 years but is a bit awkward; a new alias that fits our/your ideal naming scheme; and another with a namespace prefix which is identical except for argument order. Do you not see that that is going to be really confusing for users, no matter how clever we make the manual?
If we add such functions at all, the answer to "which one should I use and why?" should be more than "whichever one was added most recently (unless you need compatibility)". That's why a radical API like scalar methods, or just a designed from scratch set of functions, is the only sensible way to move forward.
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Thu, Mar 5, 2015 at 5:51 PM, Rowan Collins rowan.collins@gmail.com 
wrote:
Hi Rowan,
On Thu, Mar 5, 2015 at 10:16 AM, Rowan Collins
rowan.collins@gmail.com
wrote:On 4 March 2015 21:27:53 GMT, Yasuo Ohgaki yohgaki@ohgaki.net
wrote:We cannot remove all issue at once. We are better to adopt
incremental
improvement, aren't we?I think this, more than anything else, is where I disagree (having
been
persuaded by arguments in previous discussions). Incremental
improvements
mean having the cost of change multiple times, and the benefit just a
promise for the future. It's like living in a building site while
rebuilding your house - sometimes necessary, but not what you'd
choose.If we have two names with no other fixes now, then later a third
name, or
some magic flag, which fixes the argument order and error behaviour,
then
go through and tidy up, we'll end up with a whole flow chart of "if
you
need to support version X, use Y; if you find a tutorial using A,
replace
with B..."Some such change is inevitable - a huge number of tutorials became
out of
date when ext/mysql was deprecated, for instance - but it's not
something
to do "little and often" just to make things "a little bit better".Sounds reasonable. I've updated RFC to note not addressed
inconsistencies
explicitly.
There may be others.Some of these may be addressed by this RFC.
https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality
Unaffected PHP Functionality
This RFC only addresses inconsistent names. These are the list of
related
inconsistencies.
- Parameter order inconsistency. This may be addressed by “default
namespace” in other RFC.- Return type inconsistency. Most severe inconsistency is “wrong number
of parameters returns NULL”. This may be addressed by “INI switch” in
other
RFC.- Constant name inconsistency.
- Class and method names. Only “__set_state()” and “create_sid()”
methods
are addressed.Future Scope
- Use of namespace to clean up global namespace at all.
- New APIs that replace old APIs.
- Parameter order inconsistency.
- Return type inconsistency.
- Constant name inconsistency.
- Class inconsistency.
Functions return
NULLfor wrong number of parameters is easy one to fix
without BC.
We may have INI switch returnFALSEfor invalid number of parameters.return_value_consistency=On/Off ; Returns
FALSEwhen number of
parameter
is wrong for module functions.Parameter ordering issue may be addressed also. Instead of having
alias, we
may introduce new functions
for them. The new function name could be issue, though. If you know
good
list of functions have strange
parameter ordering, I appreciate it.Parameter ordering issue could be addressed by "default namespace" that
can
import functions/classes
to root namespace. This approach requires more work, but it would be
cleaner than simply having new
API. I think this issue would be large enough to be a RFC, though...Do you have particular suggestions?
You missed my point: doing this but by bit is the worst solution, not the
best. One of your suggestions implies that we'll have 3 names for the same
function: the one that's existed for 20 years but is a bit awkward; a new
alias that fits our/your ideal naming scheme; and another with a namespace
prefix which is identical except for argument order. Do you not see that
that is going to be really confusing for users, no matter how clever we
make the manual?If we add such functions at all, the answer to "which one should I use and
why?" should be more than "whichever one was added most recently (unless
you need compatibility)". That's why a radical API like scalar methods, or
just a designed from scratch set of functions, is the only sensible way to
move forward.
I've decided to address parameter ordering issue by this RFC. So one issue 
will 
be resolved. I'll explicitly state functions that have misordered 
parameters are 
subject to be deprecated. Removal should be more than a decade later 
if we ever remove them. I pasted mail content from other thread at the end 
of 
this mail. If you notice anything, please let me know.
I'll document main function as preferred function. 
New manual pages will not have dedicated pages for aliases, but aliases are 
documented as main function's alias. It will help to avoid confusions 
hopefully.
I don't think it's much problem to comply both PHP and IEEE standards. I 
even 
think it better to comply both PHP and IEEE standards as we can have both 
of 
goodies. (C/C++ programmers can easily find proper PHP functions and use it 
if they would like to, for example)
I would love to have new OO APIs for variables. I also like to write 
procedural 
code for simple scripts. Therefore, even if we have new OO APIs, I would 
like to 
improve/maintain procedural functions and make them not legacy functions.
Regards,
====================== 
On Wed, Mar 4, 2015 at 2:34 AM, Benoit Schildknecht bensor987@neuf.fr 
wrote:
I think the new functions must have consistent parameters order too. I
think it is about the right time, so we'll have a cleaner and more logical
language.ATM, it's a real headache, we constantly have to read the documentation to
make sure we give the arguments in the right order.For instance
implode(): "implode() can, for historical reasons, accept its
parameters in either order. "- strpos( $haystack, $needle )
- in_array( $needle, $haystack )
$needle should be 2nd argument like
int strpos  ( string $haystack  , mixed $needle  [, int $offset= 0  ] ) 
string stristr ( string $haystack , mixed $needle [, bool $before_needle = 
false ] )
Rasmus suggested to have IEEE 1003.1 compliance. I like the idea and I'll 
add 
this in the RFC, probably. These are the order of parameters.
So array functions are subject to be changed.
bool in_array  ( mixed $needle  , array $haystack  [, bool $strict  ] ) 
Renamed to array_in() and fix order.
mixed array_search  ( mixed $needle  , array $haystack  [, bool $strict  ] ) 
Renamed to array_find() and fix order.
bool array_key_exists ( mixed $key , array $array ) 
Renamed to array_key_find() and fix order.
array array_keys ( array $array [, mixed $search_value [, bool $strict = 
false ]] ) 
OK as it is now.
implode() may be changed to have 
string implode ( string $glue , array $pieces ) 
always.
If there are missing functions, please let me know. 
I'll try to address.
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I
would like to
improve/maintain procedural functions and make them not legacy functions.
I don't see scalar methods primarily as a way to make PHP more OO (it's 
just syntax sugar, at the end of the day), but as an opportunity to 
bring in a new API with real advantages.
As Jordi says in the other thread, there are other things you could 
improve about the array functions beyond making the argument order match 
the string functions. If you were to sit down and design a new set of 
array functions (for instance), which were a valuable replacement for 
the old ones, you wouldn't also need to add dozens of aliases to the old 
set, because your new set could have a consistent and intuitive naming 
and behaviour convention.
Scalar methods are just one way of designing that new set of functions,
but you could just make a namespace of completely redesigned functions, 
with deliberately new names to make it obvious which set was being used. 
At that point, having the aliases you're proposing would be actively 
harmful, because now users would have to ask (themselves/the 
manual/Stack Overflow) "is this the new function, or just the new name 
for the old function?"
Regards,
Rowan Collins 
[IMSoP]
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I would
like to
improve/maintain procedural functions and make them not legacy functions.I don't see scalar methods primarily as a way to make PHP more OO (it's just
syntax sugar, at the end of the day), but as an opportunity to bring in a
new API with real advantages.As Jordi says in the other thread, there are other things you could improve
about the array functions beyond making the argument order match the string
functions. If you were to sit down and design a new set of array functions
(for instance), which were a valuable replacement for the old ones, you
wouldn't also need to add dozens of aliases to the old set, because your new
set could have a consistent and intuitive naming and behaviour convention.Scalar methods are just one way of designing that new set of functions, but
you could just make a namespace of completely redesigned functions, with
deliberately new names to make it obvious which set was being used. At that
point, having the aliases you're proposing would be actively harmful,
because now users would have to ask (themselves/the manual/Stack Overflow)
"is this the new function, or just the new name for the old function?"
I will say it again a last time, in my opinion only a clean API; 
object-like or real object as long as performance is not affected is 
the only way I could see to actually solve this problem.
Changing the names, argument order (pointless once we will have named 
arguments, btw) and similar solutions are band aids solutions, 
confusing at best, terrible at worst. It is pointless to do it after 
almost two decades for some of them.
-- 
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote on 05/03/2015 11:49:
Yasuo Ohgaki wrote on 05/03/2015 09:24:
I would love to have new OO APIs for variables. I also like to write
procedural
code for simple scripts. Therefore, even if we have new OO APIs, I would
like to
improve/maintain procedural functions and make them not legacy functions.I don't see scalar methods primarily as a way to make PHP more OO (it's just
syntax sugar, at the end of the day), but as an opportunity to bring in a
new API with real advantages.As Jordi says in the other thread, there are other things you could improve
about the array functions beyond making the argument order match the string
functions. If you were to sit down and design a new set of array functions
(for instance), which were a valuable replacement for the old ones, you
wouldn't also need to add dozens of aliases to the old set, because your new
set could have a consistent and intuitive naming and behaviour convention.Scalar methods are just one way of designing that new set of functions, but
you could just make a namespace of completely redesigned functions, with
deliberately new names to make it obvious which set was being used. At that
point, having the aliases you're proposing would be actively harmful,
because now users would have to ask (themselves/the manual/Stack Overflow)
"is this the new function, or just the new name for the old function?"
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
the only way I could see to actually solve this problem.Changing the names, argument order (pointless once we will have named
arguments, btw) and similar solutions are band aids solutions,
confusing at best, terrible at worst. It is pointless to do it after
almost two decades for some of them.
For the record, I largely agree. I am open to the possibility of other 
similarly clean-break solutions, but have not seen one proposed yet. 
The fact that scalar methods would look completely different from legacy 
functions, including parameter order (because of $this), gives them a 
huge head-start over any other approach I can think of.
If "int", "string", et al acted as real classes, and participated in an 
extendable hierarchy of "value types", that would be even more awesome, 
but entirely incidental to concerns over consistency.
Regards,
Rowan Collins 
[IMSoP]
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre.php@gmail.com:
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
the only way I could see to actually solve this problem.Changing the names, argument order (pointless once we will have named
arguments, btw) and similar solutions are band aids solutions,
confusing at best, terrible at worst. It is pointless to do it after
almost two decades for some of them.--
PierreI'm with Pierre here.
Adding aliases is gonna mess up things even more. For example -
autocomplete will become hard to navigate. It's already quite lengthy list
a lot of the times and it's easier just to write the whole function name
sometimes by hand. Adding aliases will make it worse.
We really need a new API, that is not crossing paths with the old. That way 
people can start building stuff on new API's and we could phase out the old 
mess, for example: depricate in PHP8, remove in PHP9. 
Stop-gap measures have created enough problems already, or did everyone 
suddenly got an amnesia and forgot all the past lessons on the list?
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godjuks@gmail.com 
wrote:
2015-03-05 13:49 GMT+02:00 Pierre Joye pierre.php@gmail.com:
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
the only way I could see to actually solve this problem.Changing the names, argument order (pointless once we will have named
arguments, btw) and similar solutions are band aids solutions,
confusing at best, terrible at worst. It is pointless to do it after
almost two decades for some of them.--
PierreI'm with Pierre here.
Adding aliases is gonna mess up things even more. For example -
autocomplete will become hard to navigate. It's already quite lengthy list
a lot of the times and it's easier just to write the whole function name
sometimes by hand. Adding aliases will make it worse.
I agree. Therefore, I'm going to update manual also so that it recommends 
main function, not aliases. Aliases should be alternative.
Manual and IDE don't have to list all of them. New manual lists only main 
functions, does not have dedicated pages for aliases but aliases are 
mentioned 
in main function page as aliases.
We really need a new API, that is not crossing paths with the old. That way
people can start building stuff on new API's and we could phase out the old
mess, for example: depricate in PHP8, remove in PHP9.
Stop-gap measures have created enough problems already, or did everyone
suddenly got an amnesia and forgot all the past lessons on the list?
PHP should be multi paradigm language, not pure OO language. 
IMO. Python does good job.
"Python is a multi-paradigm programming language: object-oriented 
programming 
and structured programming are fully supported, and there are a number of 
language features which support functional programming and aspect-oriented 
programming" 
http://en.wikipedia.org/wiki/Python_%28programming_language%29
It sounds like there are people who would like to discard procedural APIs. 
PHP has born as procedural language. It will not happen in short term at 
least. We are far from having rich and good enough OO APIs sets to make 
PHP a pure OO languages.
This leads to conclusion that we need to maintain/improve procedural APIs 
even if we are going to make PHP a pure OO language.
I finally understand why some of us against this change and suggest OO APIs 
as alternative. It's reasonable making procedural APIs a 
legacy/unmaintained/ 
messed up to discard  procedural APIs someday. I'm against it. PHP should 
be like Python in this regard. IMO.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
<arvids.godjuks@gmail.com mailto:arvids.godjuks@gmail.com> wrote:2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre.php@gmail.com <mailto:pierre.php@gmail.com>>: > > > I will say it again a last time, in my opinion only a clean API; > object-like or real object as long as performance is not affected is > the only way I could see to actually solve this problem. > > Changing the names, argument order (pointless once we will have named > arguments, btw) and similar solutions are band aids solutions, > confusing at best, terrible at worst. It is pointless to do it after > almost two decades for some of them. > > -- > Pierre > > I'm with Pierre here. Adding aliases is gonna mess up things even more. For example - autocomplete will become hard to navigate. It's already quite lengthy list a lot of the times and it's easier just to write the whole function name sometimes by hand. Adding aliases will make it worse.I agree. Therefore, I'm going to update manual also so that it recommends
main function, not aliases. Aliases should be alternative.Manual and IDE don't have to list all of them. New manual lists only main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.
You can't fix everyone's IDEs for them. You can't fix all the 
documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of 
all, you can't fix the thousands of projects already written in PHP 
using the "wrong" function names, most of which will want to continue 
using those function names, because that will be internally consistent, 
and portable between versions.
The problems people are pointing out are not ones that you can promise 
to fix.
We really need a new API, that is not crossing paths with the old. That way people can start building stuff on new API's and we could phase out the old mess, for example: depricate in PHP8, remove in PHP9. Stop-gap measures have created enough problems already, or did everyone suddenly got an amnesia and forgot all the past lessons on the list?PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job.
The paragraph you are replying to says "new API". It does not say "pure 
OO". As I've said before, the relevance of scalar methods is not that 
objects are cool and functions are boring; it's that they're something 
new we can design from scratch without worrying about the 20 years of 
legacy the existing API has.
I finally understand why some of us against this change and suggest OO
APIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP should
be like Python in this regard. IMO.
OK, so let's look at our options to maintain the language as multi-paradigm:
- 
Implement piecemeal tweaks to the current API, adding to the 
 confusion of users, in the hope that eventually we accumulate enough
 fixes, everyone gets used to them, the old ones die away somehow, and
 the result is a slightly nicer set of functions, with various awkward
 compromises along the way.
- 
Find a way of designing a clean-break new API which is still 
 procedural. More than just a namespace, which is basically just some new
 names with \ in; and definitely not something where the same code can
 mean a different thing depending on a setting or import at the top of
 the file. Something which will feel fresh, which users will want to
 start using, and will recognise when they see code using it.
I don't what that might look like, but if you have some ideas, that is 
how you will move this discussion forward, with a radical new solution; 
everything you have said so far are things which have been said over and 
over again before. Come up with something which nobody has thought of 
before, or take our word for it that everyone who has previously 
proposed this has failed.
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks <arvids.godjuks@gmail.com
mailto:arvids.godjuks@gmail.com> wrote:2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre.php@gmail.com <mailto:pierre.php@gmail.com>>: > > > I will say it again a last time, in my opinion only a clean API; > object-like or real object as long as performance is not affected is > the only way I could see to actually solve this problem. > > Changing the names, argument order (pointless once we will have named > arguments, btw) and similar solutions are band aids solutions, > confusing at best, terrible at worst. It is pointless to do it after > almost two decades for some of them. > > -- > Pierre > > I'm with Pierre here. Adding aliases is gonna mess up things even more. For example - autocomplete will become hard to navigate. It's already quite lengthy list a lot of the times and it's easier just to write the whole function name sometimes by hand. Adding aliases will make it worse.I agree. Therefore, I'm going to update manual also so that it recommends
main function, not aliases. Aliases should be alternative.Manual and IDE don't have to list all of them. New manual lists only main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.You can't fix everyone's IDEs for them. You can't fix all the
documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of
all, you can't fix the thousands of projects already written in PHP using
the "wrong" function names, most of which will want to continue using
those function names, because that will be internally consistent, and
portable between versions.The problems people are pointing out are not ones that you can promise to
fix.
The same argument applies to OO API alternative. 
It's impossible update documents/etc to use new OO API as you mentioned.
My proposal only requires simple replace. Even simple replace would not be 
needed since old names work as should be. Users can know what's the main 
function by looking up manual.
It does not seem new OO API will do better job as it may have completely 
different method names and syntax.
We really need a new API, that is not crossing paths with the old. That way people can start building stuff on new API's and we could phase out the old mess, for example: depricate in PHP8, remove in PHP9. Stop-gap measures have created enough problems already, or did everyone suddenly got an amnesia and forgot all the past lessons on the list?PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job.The paragraph you are replying to says "new API". It does not say "pure
OO". As I've said before, the relevance of scalar methods is not that
objects are cool and functions are boring; it's that they're something new
we can design from scratch without worrying about the 20 years of legacy
the existing API has.
I'm against making procedural API legacy so that someone would not propose
"Let's discard legacy, messy and inconsistent procedural API at all"
We should keep good procedural API forever. 
Procedural API has good set of well defined API such as IEEE 1003.1. PHP 
also defines good set of procedural APIs. These APIs do not need radical 
changes, but 
only small improvement and adjustment is enough like this RFC proposes. 
(I'll add parameter order issue handling proposal later)
I finally understand why some of us against this change and suggest OO
APIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP should
be like Python in this regard. IMO.OK, so let's look at our options to maintain the language as
multi-paradigm:
- Implement piecemeal tweaks to the current API, adding to the confusion
of users, in the hope that eventually we accumulate enough fixes, everyone
gets used to them, the old ones die away somehow, and the result is a
slightly nicer set of functions, with various awkward compromises along the
way.
I'm going to adopt your suggestions. One is parameter ordering which have 
been issue for a long time. I'll address this issue with this RFC.
========== 
$needle should be 2nd argument like
int strpos  ( string $haystack  , mixed $needle  [, int $offset= 0  ] ) 
string stristr ( string $haystack , mixed $needle [, bool $before_needle = 
false ] )
Rasmus suggested to have IEEE 1003.1 compliance. I like the idea and I'll 
add 
this in the RFC, probably. These are the order of parameters.
So array functions are subject to be changed.
bool in_array  ( mixed $needle  , array $haystack  [, bool $strict  ] ) 
Renamed to array_in() and fix order.
mixed array_search  ( mixed $needle  , array $haystack  [, bool $strict  ] ) 
Renamed to array_find() and fix order.
bool array_key_exists ( mixed $key , array $array ) 
Renamed to array_key_find() and fix order.
array array_keys ( array $array [, mixed $search_value [, bool $strict = 
false ]] ) 
OK as it is now.
implode() may be changed to have 
string implode ( string $glue , array $pieces ) 
always.
As I mentioned, small improvements and adjustments would be enough to keep 
procedural APIs forever. If my proposal is not good enough to keep 
procedural API for good, please 
suggest what's missing.
- Find a way of designing a clean-break new API which is still procedural.
More than just a namespace, which is basically just some new names with
in; and definitely not something where the same code can mean a different
thing depending on a setting or import at the top of the file. Something
which will feel fresh, which users will want to start using, and will
recognise when they see code using it.
I probably don't understand well what you meant here. 
If we have default namespace to be imported to "" namespace and user could 
choose which names to import, we have zero BC for completely new APIs for 
both OO and 
procedural APIs. (We have a beast, constants defined by define(), though)
I'm not suggesting radical improvement for procedural APIs. Both PHP and 
IEEE procedural APIs are well established. Only small modifications are 
needed, IMO.
I don't what that might look like, but if you have some ideas, that is how
you will move this discussion forward, with a radical new solution;
everything you have said so far are things which have been said over and
over again before. Come up with something which nobody has thought of
before, or take our word for it that everyone who has previously proposed
this has failed.
What do you mean by "take our word for it that everyone who has previously 
proposed this has failed."?
As I mentioned, there are group of people who would like to "remove 
procedural API completely and make PHP a pure OO language in the future". I 
understand the motivation very well. It's possible option. However, I don't 
think we have consensus for "removing procedural API completely and make 
PHP a pure OO language in the future".
The reason why previous proposals have failed is aggressive OO supporter 
rejected "procedural API improvement", isn't it?
Let's see how it goes by vote. This vote is going to be whether we'll take 
direction to pure OO or multi-paradigm.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.collins@gmail.com
wrote:Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
<arvids.godjuks@gmail.com
mailto:arvids.godjuks@gmail.com> wrote:2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre.php@gmail.com <mailto:pierre.php@gmail.com>>: > > > I will say it again a last time, in my opinion only a cleanAPI;
> object-like or real object as long as performance is notaffected is
> the only way I could see to actually solve this problem. > > Changing the names, argument order (pointless once we willhave
named > arguments, btw) and similar solutions are band aids solutions, > confusing at best, terrible at worst. It is pointless to do itafter
> almost two decades for some of them. > > -- > Pierre > > I'm with Pierre here. Adding aliases is gonna mess up things even more. For example - autocomplete will become hard to navigate. It's already quite lengthy list a lot of the times and it's easier just to write the whole function name sometimes by hand. Adding aliases will make it worse.I agree. Therefore, I'm going to update manual also so that it
recommends
main function, not aliases. Aliases should be alternative.Manual and IDE don't have to list all of them. New manual lists only
main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.You can't fix everyone's IDEs for them. You can't fix all the
documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of
all, you can't fix the thousands of projects already written in PHP
using
the "wrong" function names, most of which will want to continue
using
those function names, because that will be internally consistent, and
portable between versions.The problems people are pointing out are not ones that you can
promise to
fix.The same argument applies to OO API alternative.
It's impossible update documents/etc to use new OO API as you
mentioned.My proposal only requires simple replace. Even simple replace would not
be
needed since old names work as should be. Users can know what's the
main
function by looking up manual.It does not seem new OO API will do better job as it may have
completely
different method names and syntax.
That's actually the advantage of an OO-style API - it's really obvious which set of functions someone else is using, and really easy to look at the two side by side.
Users will not spend their time cross-referencing every function they see in a tutorial against the manual to see if it's been renamed with some extra underscores, and whether the new name has a different parameter order or error behaviour. But they might well read an article on how in version X, you can write things with this different syntax, and they'd instantly see that the old tutorial they found wasn't using that syntax.
We really need a new API, that is not crossing paths with theold.
That way people can start building stuff on new API's and we could phase out the old mess, for example: depricate in PHP8, remove in PHP9. Stop-gap measures have created enough problems already, or did everyone suddenly got an amnesia and forgot all the past lessons on thelist?
PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job.The paragraph you are replying to says "new API". It does not say
"pure
OO". As I've said before, the relevance of scalar methods is not that
objects are cool and functions are boring; it's that they're
something new
we can design from scratch without worrying about the 20 years of
legacy
the existing API has.I'm against making procedural API legacy so that someone would not
propose"Let's discard legacy, messy and inconsistent procedural API at all"
Again, you bring it back to the assumption that "new API" means "not procedural any more". I'm not sure how many different ways I can find of saying that's not the point.
We should keep good procedural API forever.
Procedural API has good set of well defined API such as IEEE 1003.1.
PHP
also defines good set of procedural APIs. These APIs do not need
radical
changes, but
only small improvement and adjustment is enough like this RFC proposes.
(I'll add parameter order issue handling proposal later)I finally understand why some of us against this change and suggest
OOAPIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP
should
be like Python in this regard. IMO.OK, so let's look at our options to maintain the language as
multi-paradigm:
- Implement piecemeal tweaks to the current API, adding to the
confusion
of users, in the hope that eventually we accumulate enough fixes,
everyone
gets used to them, the old ones die away somehow, and the result is a
slightly nicer set of functions, with various awkward compromises
along the
way.I'm going to adopt your suggestions. One is parameter ordering which
have
been issue for a long time. I'll address this issue with this RFC.
Please don't credit me with that suggestion. It comes up just as often as the naming consistency, with just as much lack of support. Hence the bullet on the "mysterious PHP RFC process" blog post requesting that nobody try to put forward an RFC for either of them.
As I mentioned, small improvements and adjustments would be enough to
keep
procedural APIs forever. If my proposal is not good enough to keep
procedural API for good, please
suggest what's missing.
It's not that it doesn't do enough to keep the API around - frankly, I can't see those functions going away whatever happens. It's that it doesn't do enough for people to want to start using the new functions. Who is going to bother replacing all their instances of in_array with array_in?
- Find a way of designing a clean-break new API which is still
procedural.More than just a namespace, which is basically just some new names
with
in; and definitely not something where the same code can mean a
different
thing depending on a setting or import at the top of the file.
Something
which will feel fresh, which users will want to start using, and will
recognise when they see code using it.I probably don't understand well what you meant here.
If we have default namespace to be imported to "" namespace and user
could
choose which names to import, we have zero BC for completely new APIs
for
both OO and
procedural APIs. (We have a beast, constants defined bydefine(),
though)
I used to really like the idea of a namespace with all the new functions in, and indeed the bulk import/default namespace idea, but I realised it doesn't really help. You have zero BC, but you also have a language which is incredibly hard to read, because the same line of code will do different things based on whether the file begins with a particular "use" statement. And now, rather than being confused about whether array_key_exists takes needle first or second, users have to be confused that it sometimes works one way, and sometimes the other, depending on which namespace they're operating in.
I'm not suggesting radical improvement for procedural APIs. Both PHP
and
IEEE procedural APIs are well established. Only small modifications are
needed, IMO.I don't what that might look like, but if you have some ideas, that
is how
you will move this discussion forward, with a radical new solution;
everything you have said so far are things which have been said over
and
over again before. Come up with something which nobody has thought of
before, or take our word for it that everyone who has previously
proposed
this has failed.What do you mean by "take our word for it that everyone who has
previously
proposed this has failed."?
I mean that you are approaching this with the enthusiasm of someone bringing a new idea to the table, and trying to win over people who've been working on the prioject for years. But the fact is that this conversation has been had before, many times over, and it has never been adopted before. You have very little chance of getting it adopted this time.
As I mentioned, there are group of people who would like to "remove
procedural API completely and make PHP a pure OO language in the
future". I
understand the motivation very well. It's possible option. However, I
don't
think we have consensus for "removing procedural API completely and
make
PHP a pure OO language in the future".
There may be such people, yes. But they are not your main problem in getting your proposal adopted. Your main problem are two groups:
- those who think it is far too late to change any of this, and that it's just not worth the hassle for a few minor annoyances
- those who think that it might be justifiable if we can find a way of making a compelling new set of functions, rather than just tweaking a few corner cases
The reason why previous proposals have failed is aggressive OO
supporter
rejected "procedural API improvement", isn't it?
No. That is a relatively recent phenomenon, if it's real at all. The reason previous proposals have failed is that people think the costs outweigh the benefits.
Let's see how it goes by vote. This vote is going to be whether we'll
take
direction to pure OO or multi-paradigm.
No, the only vote we can have right now is on the option on the table, so will be whether it's worth the pain to change things which have worked this way for twenty years. There is no proposal on the table for making PHP an OO only language, and I'm not even sure what such a proposal would look like at this point in time.
PHP is not in imminent danger of death if we leave a handful of string and array functions with slightly awkward names and behaviour, so it's not like we've got to choose between two rescue plans, messing with the functions or jumping into OO.
I get that you find those functions annoying, but not everyone agrees with you. Maybe I'm wrong and there's a silent majority willing to push this through, but I would be extremely surprised if a vote on this was anything other than a landslide "no thanks".
Regards,
Rowan Collins 
[IMSoP]
Hi Rowan,
On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
Hi Rowan,
On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins rowan.collins@gmail.com
wrote:Yasuo Ohgaki wrote on 05/03/2015 20:20:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
<arvids.godjuks@gmail.com
mailto:arvids.godjuks@gmail.com> wrote:2015-03-05 13:49 GMT+02:00 Pierre Joye <pierre.php@gmail.com <mailto:pierre.php@gmail.com>>: > > > I will say it again a last time, in my opinion only a cleanAPI;
> object-like or real object as long as performance is notaffected is
> the only way I could see to actually solve this problem. > > Changing the names, argument order (pointless once we willhave
named > arguments, btw) and similar solutions are band aids solutions, > confusing at best, terrible at worst. It is pointless to do itafter
> almost two decades for some of them. > > -- > Pierre > > I'm with Pierre here. Adding aliases is gonna mess up things even more. For example - autocomplete will become hard to navigate. It's already quite lengthy list a lot of the times and it's easier just to write the whole function name sometimes by hand. Adding aliases will make it worse.I agree. Therefore, I'm going to update manual also so that it
recommends
main function, not aliases. Aliases should be alternative.Manual and IDE don't have to list all of them. New manual lists only
main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.You can't fix everyone's IDEs for them. You can't fix all the
documentation (tutorials, blogs, Q&As) not hosted on php.net. Most of
all, you can't fix the thousands of projects already written in PHP
using
the "wrong" function names, most of which will want to continue
using
those function names, because that will be internally consistent, and
portable between versions.The problems people are pointing out are not ones that you can
promise to
fix.The same argument applies to OO API alternative.
It's impossible update documents/etc to use new OO API as you
mentioned.My proposal only requires simple replace. Even simple replace would not
be
needed since old names work as should be. Users can know what's the
main
function by looking up manual.It does not seem new OO API will do better job as it may have
completely
different method names and syntax.That's actually the advantage of an OO-style API - it's really obvious
which set of functions someone else is using, and really easy to look at
the two side by side.Users will not spend their time cross-referencing every function they see
in a tutorial against the manual to see if it's been renamed with some
extra underscores, and whether the new name has a different parameter order
or error behaviour. But they might well read an article on how in version
X, you can write things with this different syntax, and they'd instantly
see that the old tutorial they found wasn't using that syntax.
We have ArrayObject. 
http://php.net/manual/en/class.arrayobject.php 
I'm not a supporter of this class. Both class name and methods are not good 
enough. Implementation seems complex overly.
It sounds like you are going to oppose to have improved array classes 
and/or array variable OO extension for the same reason.
- Do you oppose to have better array class alternatives because of 
 ArrayObject?
- Do you think we must stick to this class/methods because it's already 
 been here for a long time?
- Do you oppose to have array variable object, i.e. $var_array->sort(), 
 because we have ArrayObject already?
- Do you agree if I object to have new/better OO API by existence of 
 ArrayObject?
We really need a new API, that is not crossing paths with theold.
That way people can start building stuff on new API's and we could phase out the old mess, for example: depricate in PHP8, remove in PHP9. Stop-gap measures have created enough problems already, or did everyone suddenly got an amnesia and forgot all the past lessons on thelist?
PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job.The paragraph you are replying to says "new API". It does not say
"pure
OO". As I've said before, the relevance of scalar methods is not that
objects are cool and functions are boring; it's that they're
something new
we can design from scratch without worrying about the 20 years of
legacy
the existing API has.I'm against making procedural API legacy so that someone would not
propose"Let's discard legacy, messy and inconsistent procedural API at all"
Again, you bring it back to the assumption that "new API" means "not
procedural any more". I'm not sure how many different ways I can find of
saying that's not the point.
I thought you prefer to have scalar object (including array) rather than 
procedural API fix/improvement. I'm lost here. So how would you like to fix 
naming mess and parameter miss ordering issue in procedural APIs? Leave 
inconsistent procedural functions forever?
We should keep good procedural API forever.
Procedural API has good set of well defined API such as IEEE 1003.1.
PHP
also defines good set of procedural APIs. These APIs do not need
radical
changes, but
only small improvement and adjustment is enough like this RFC proposes.
(I'll add parameter order issue handling proposal later)I finally understand why some of us against this change and suggest
OOAPIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP
should
be like Python in this regard. IMO.OK, so let's look at our options to maintain the language as
multi-paradigm:
- Implement piecemeal tweaks to the current API, adding to the
confusion
of users, in the hope that eventually we accumulate enough fixes,
everyone
gets used to them, the old ones die away somehow, and the result is a
slightly nicer set of functions, with various awkward compromises
along the
way.I'm going to adopt your suggestions. One is parameter ordering which
have
been issue for a long time. I'll address this issue with this RFC.Please don't credit me with that suggestion. It comes up just as often as
the naming consistency, with just as much lack of support. Hence the bullet
on the "mysterious PHP RFC process" blog post requesting that nobody try to
put forward an RFC for either of them.As I mentioned, small improvements and adjustments would be enough to
keep
procedural APIs forever. If my proposal is not good enough to keep
procedural API for good, please
suggest what's missing.It's not that it doesn't do enough to keep the API around - frankly, I
can't see those functions going away whatever happens. It's that it doesn't
do enough for people to want to start using the new functions. Who is going
to bother replacing all their instances of in_array with array_in?
I agree that old functions should be able to use. Old name aliases should 
stay forever. Users do not have to rewrite their code with this RFC. They 
can use old names as long as they wish. Old codes are not invalid code, but 
perfectly valid code.
So your idea is to leaving behind procedural API inconsistencies forever 
and keep as it is?
- Find a way of designing a clean-break new API which is still
procedural.More than just a namespace, which is basically just some new names
with
in; and definitely not something where the same code can mean a
different
thing depending on a setting or import at the top of the file.
Something
which will feel fresh, which users will want to start using, and will
recognise when they see code using it.I probably don't understand well what you meant here.
If we have default namespace to be imported to "" namespace and user
could
choose which names to import, we have zero BC for completely new APIs
for
both OO and
procedural APIs. (We have a beast, constants defined bydefine(),
though)I used to really like the idea of a namespace with all the new functions
in, and indeed the bulk import/default namespace idea, but I realised it
doesn't really help. You have zero BC, but you also have a language which
is incredibly hard to read, because the same line of code will do different
things based on whether the file begins with a particular "use" statement.
And now, rather than being confused about whether array_key_exists takes
needle first or second, users have to be confused that it sometimes works
one way, and sometimes the other, depending on which namespace they're
operating in.
I agree. Flexibility comes with its cost. It's possible to write incredibly 
hard to read code with Ruby/JavaScript/Scheme/etc. 
This is one of the reason why I didn't propose "namespace" use. Keeping RFC 
simple is better to discuss targeted issue.
Even without such feature, we may do
PHP FizzBuzz http://3v4l.org/KFRj6 
<? $_ = ("@]@@]@"^"#/%!)%")..("@]@@]@@@"^"&(.#))/."); 
$=$('$,$',' 
$ = !""; 
$$ = +""; 
$___ = $_ + $_ + $; 
$____ = $+$+$; 
$$$ ="|@@@"^":)::"; 
$$$$_ = "|]@@"^">(::"; 
$$___ = "]]).]:"^"-/@@)\"; 
$$(($%($ . $)?$%$?$%$?$:$$$:$$$$:$$$.$$$$)." 
"); 
$- ($ . $$_  . $$) && $($+!"",$); '); 
$(!'',$_);
Ruby FizzBuzz 
$="#"=~/$/;$=$+$;$=$+$;$=$+$;$=$+ 
$;@@=""<<($*$$+$); @@=""<<($_$*$);@=""<<($* 
$*$); @=""<<($**$-$**$);@=""<<($**$-$);@<<@;= 
->(){>$&&.(-$);($><<[%$<$?(@@+@+@):%$>(""=~ 
//)?:'',[@@+@+@][%$]]*''+(""<<($*$)))};.($*$*$*$_)
JavaScript FizzBuzz 
$=+[];$={:$++,$:$++,$:$++,$$:$++,$:$++,$$:$++,$$:$++,$$$:$++};=($. 
)[({}+"")[$.$$]+({}+"")[$.$]+({}.$+"")[$.$]+(!{}+"")[$.$$]+(!!{}+"")[$ 
.]+(!!{}+"")[$.$]+({}.$+"")[$.]+({}+"")[$.$$]+(!!{}+"")[$.]+({}+"") 
[$.$]+(!!{}+"")[$.$]][({}+"")[$.$$]+({}+"")[$.$]+({}.$+"")[$.$]+(!{}+ 
"")[$.$$]+(!!{}+"")[$.]+(!!{}+"")[$.$]+({}.$+"")[$.]+({}+"")[$.$$]+(! 
!{}+"")[$.]+({}+"")[$.$]+(!!{}+"")[$.$]]((!!{}+"")[$.$]+(!!{}+"")[$.$$ 
]+(!!{}+"")[$.]+(!!{}+"")[$.$]+(!!{}+"")[$.$]+({}.$+"")[$.$]+"""+"\" 
+$.$+$.$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$+$.$$$+"\"+$.$+$.$$$+"\"+$.$$$ 
+$.$$+"\"+$.$+$.$+$.$$+"\"+$.$+$.$$+$.$$$+"\"+$.$+$.$$+$.$+"\" 
+$.$$+$.+"\"+$.$+$.$$+$.$+"\"+$.$$$+$.$$+"\"+$.$$+$.$+"\"+$.$$$ 
+$.$$+"\"+$.$+$.$$+$.$+"\"+$.$$$+$.$+"\"+$.$$$+$.$$+"\"+$.$$+$.$ 
+"\"+$.$$+$.+"\"+$.$$+$.+"\"+$.$$$+$.$$+"\"+$.$$+$.$$+"\"+$.$$+ 
$.$$+"\"+$.$+$.$$+$.$+"\"+$.$$+$.$+"\"+$.$+$.$$$+$.$$+"\"+$.$+ 
$.$$+$.$$+"\"+$.$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$$+$.+"\"+$.$+$.$$+ 
$.$+"\"+$.$+$.$$+"\"+$.$$+$.$+"\"+$.$$+$.$$+"\"+$.$$$+$.$$+"\"+$ 
.$$$+$.$$+"\"+$.$$+$.+"\"+$.$$$+$.$$$+"\"+$.$+$.$$$+"\"+$.$+$.+$ 
.$$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$$+$.$+"\"+$ 
.$+$.+$.$+"\"+$.$+$.$$+$.$$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$$+ 
$.$+"\"+$.$+$.$$$+"\"+$.$$$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$+ 
"\"+$.$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$$+$.+"\"+$.$$$+$ 
.$$$+"\"+$.$+$.$$$+"\"+$.$+$.+$.$$+"\"+$.$+$.$$+$.$+"\"+$.$+$ 
.$$$+$.$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$$+"\"+$.$$$+$.$+"\"+$.$+$ 
.$$+$.$+"\"+$.$+$.$$+"\"+$.$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$$$+$.$$+ 
"\"+$.$$+$.+"\"+$.$$$+$.$$$+"\"+$.$+$.$$$+"\"+$.$+$.+$.$+"\"+$ 
.$+$.$$+$.$$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$$+ 
"\"+$.$$$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$$+$.$+"\"+$.$$+$.$$+"\"+$ 
.$+$.$$$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$+$.$$+"\"+$.$+$.$$$+"\"+$ 
.$+$.$$$+$.$$+"\"+$.$+$.$+$.$$+"\"+$.$$$+$.$$+"\"+$.$$+$.+"\"+$ 
.$+$.$$+$.$+"\"+$.$+$.$$$+$.$+"\"+$.$+$.$$+$.+"\"+$.$+$.$+ 
$.$$+"\"+$.$+$.$$+$.$$$+"\"+$.$+$.$+$.$$+"\"+$.$+$.+"\"+$.$+ 
$.$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$+$.$$+"\"+$.$+$.$$+$.$ 
+"\"+$.$+$.$$+$.$+"\"+$.$$$+$.$$+"\"+$.$$$+$.$$+"\"+$.$+$.$$$+"\"+ 
$.$+$.$+$.$$+"\"+$.$+$.$$+$.$$+"\"+$.$+$.$$+$.$$+"\"+$.$+$.$ 
+$.$$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$+$.$$$+"\" 
+$.$+$.$$+$.$$+"\"+$.$+$.$$$+"\"+$.$$+$.$+"\"+$.$$$+$.$$$+"\"+$.$ 
+$.$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$+$.$$+"\"+$.$+$.$$+$. 
$+"\"+$.$+$.$$+$.$+"\"+$.$$$+$.$+"\"+$.$+$.$$+$.+"\"+$.$+$ 
.$$+$.$+"\"+$.$+$.$$+$.$+"\"+$.$+$.$$+$.$$+"\"+$.$+$.$$+$.$__ 
+"\"+$.$$$+$.$$+"\"+$.$+$.$+$.$$+"\"+$.$$+$.+"\"+$.$+$.$$+$.$$ 
+"\"+$.$$+$.$+""");($.)[({}+"")[$.$$]+({}+"")[$.$]+({}.$+"")[$.$]+( 
!{}+"")[$.$$]+(!!{}+"")[$.]+(!!{}+"")[$.$]+({}.$+"")[$.]+({}+"")[$.$$] 
+(!!{}+"")[$.]+({}+"")[$.$]+(!!{}+"")[$.__$]]({}+"")[$.$$]+({}+"")[$.$] 
+({}.$+"")[$.$]+(!{}+"")[$.$$]+(!!{}+"")[$.]+(!!{}+"")[$.$]+({}.$+"")[$. 
]+({}+"")[$.$$]+(!!{}+"")[$.]+({}+"")[$.$]+(!!{}+"")[$.$]()
I'm not suggesting radical improvement for procedural APIs. Both PHP
and
IEEE procedural APIs are well established. Only small modifications are
needed, IMO.I don't what that might look like, but if you have some ideas, that
is how
you will move this discussion forward, with a radical new solution;
everything you have said so far are things which have been said over
and
over again before. Come up with something which nobody has thought of
before, or take our word for it that everyone who has previously
proposed
this has failed.What do you mean by "take our word for it that everyone who has
previously
proposed this has failed."?I mean that you are approaching this with the enthusiasm of someone
bringing a new idea to the table, and trying to win over people who've been
working on the prioject for years. But the fact is that this conversation
has been had before, many times over, and it has never been adopted before.
You have very little chance of getting it adopted this time.
You are probably right. 
There were roughly 4 groups of people.
- Inconsistent/legacy procedural API must be replaced by new/better OO API
- Do not care consistency and keep it as it is now.
- Some current names are good enough and should not be removed. (e.g. 
 IEEE/C lib based names)
- Consistent naming is important.
1, 2 and 3 are majority. I added IEEE/lib names as a part of PHP standard 
names. 
There will be more supporters hopefully, but it seems it's not enough.
As I mentioned, there are group of people who would like to "remove
procedural API completely and make PHP a pure OO language in the
future". I
understand the motivation very well. It's possible option. However, I
don't
think we have consensus for "removing procedural API completely and
make
PHP a pure OO language in the future".There may be such people, yes. But they are not your main problem in
getting your proposal adopted. Your main problem are two groups:
- those who think it is far too late to change any of this, and that it's
just not worth the hassle for a few minor annoyances- those who think that it might be justifiable if we can find a way of
making a compelling new set of functions, rather than just tweaking a few
corner cases
Thank you for the analysis. It's reasonable one. I should think how to 
persuade them.
Changes are never too late! Especially non destructive change like this 
RFC.
Why one, who is using old names already, should care for new names? Old 
names are valid names still and stay forever. Codes or 3rd party manuals do 
not have to be updated only for this RFC. It's users/writers option whether 
to use new names or not. In case of rewrite, simple rewrite is good enough 
unlike new OO API, except a few functions that have different parameter 
order.
The reason why previous proposals have failed is aggressive OO
supporter
rejected "procedural API improvement", isn't it?No. That is a relatively recent phenomenon, if it's real at all. The
reason previous proposals have failed is that people think the costs
outweigh the benefits.
I saw many "There should be better OO API for them and use them" for PHP5 
discussion also.
I don't understand the reasoning "costs outweigh the benefits". It sounds 
like excuse for promoting OO API for me. Use of new OO API requires new 
codes/manuals. It's more than aliasing. Cost of having new name disappears 
over time while cost of having inconsistent names accumulate.
Let's see how it goes by vote. This vote is going to be whether we'll
take
direction to pure OO or multi-paradigm.No, the only vote we can have right now is on the option on the table, so
will be whether it's worth the pain to change things which have worked this
way for twenty years. There is no proposal on the table for making PHP an
OO only language, and I'm not even sure what such a proposal would look
like at this point in time.PHP is not in imminent danger of death if we leave a handful of string and
array functions with slightly awkward names and behaviour, so it's not like
we've got to choose between two rescue plans, messing with the functions or
jumping into OO.I get that you find those functions annoying, but not everyone agrees with
you. Maybe I'm wrong and there's a silent majority willing to push this
through, but I would be extremely surprised if a vote on this was anything
other than a landslide "no thanks".
Again. This RFC is not a destructive RFC at all. Good changes are never too 
late. Almost all languages does this kind of maintenance/improvement, even 
destructive changes like dropping old syntax/etc.
Unless one is not willing to replace/eliminate legacy and messy procedural 
API,  I don't understand the reasoning to object to have consistent names. 
It's new consistent names that can be used optionally. Old names are 
available probably forever.
I do rename for my codes to keep it consistent all the time. We do rename 
PHP internal code to keep it nice and consistent on occasions. I fail to 
see why not PHP functions, why not giving users a chance to use nice and 
consistent names if users would like to.
Anyway, your opinions to summarize:
- User should use new/better OO API. (And we should focus new OO API 
 development)
- Inconsistent names should be kept forever.
- This RFC requires existing manual/code rewrites. Therefore, this RFC 
 does not worth to adopt.
Is this correct? I find a little contradictory opinions here... We need 
completely new manuals/codes for new OO API while this RFC does not.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
> Hi Rowan,
>
> On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins
>
> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki
> >Hi Rowan,
> >
> >On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins
>
> >wrote:
> >
> >> Yasuo Ohgaki wrote on 05/03/2015 20:20:
> >>
> >>> Hi Arvids,
> >>>
> >>> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
> >
> >>>
> >>>
> >>> 2015-03-05 13:49 GMT+02:00 Pierre Joye
>
> >>>
> >>> >
> >>> >
> >>> > I will say it again a last time, in my opinion only a clean
> >API;
> >>> > object-like or real object as long as performance is not
> >affected is
> >>> > the only way I could see to actually solve this problem.
> >>> >
> >>> > Changing the names, argument order (pointless once we will
> >have
> >>> named
> >>> > arguments, btw) and similar solutions are band aids
> solutions,
> >>> > confusing at best, terrible at worst. It is pointless to
> do it
> >after
> >>> > almost two decades for some of them.
> >>> >
> >>> > --
> >>> > Pierre
> >>> >
> >>> > I'm with Pierre here.
> >>> Adding aliases is gonna mess up things even more. For
> example -
> >>> autocomplete will become hard to navigate. It's already quite
> >>> lengthy list
> >>> a lot of the times and it's easier just to write the whole
> >>> function name
> >>> sometimes by hand. Adding aliases will make it worse.
> >>>
> >>>
> >>> I agree. Therefore, I'm going to update manual also so that it
> >recommends
> >>> main function, not aliases. Aliases should be alternative.
> >>>
> >>> Manual and IDE don't have to list all of them. New manual
> lists only
> >main
> >>> functions, does not have dedicated pages for aliases but
> aliases are
> >>> mentioned
> >>> in main function page as aliases.
> >>>
> >>
> >>
> >> You can't fix everyone's IDEs for them. You can't fix all the
> >> documentation (tutorials, blogs, Q&As) not hosted on php.net
>
> >> all, you can't fix the thousands of projects already written in PHP
> >using
> >> the "wrong" function names, most of which will want to *continue*
> >using
> >> those function names, because that will be internally
> consistent, and
> >> portable between versions.
> >>
> >> The problems people are pointing out are not ones that you can
> >promise to
> >> fix.
> >>
> >
> >The same argument applies to OO API alternative.
> >It's impossible update documents/etc to use new OO API as you
> >mentioned.
>
To an extent, yes. Part of the point that I and others are making is
that this is not a simple change to make. Whatever we do to try and
"fix" the current inconsistencies comes at a cost, and we need to be
very careful in justifying that cost.
> >
> >My proposal only requires simple replace. Even simple replace
> would not
> >be
> >needed since old names work as should be. Users can know what's the
> >main
> >function by looking up manual.
>
You have to do at least a bit of code parsing, because you wouldn't want
to change things like echo 'Your site has exploded!'; or function
check_blob_is_in_array_twice() { ... }
So this really comes to the same thing whatever changes we make - people
can either run a converter tool over their code (and create some noise
in the version control history) or you carry on using the old functions
and get no benefit from the change.
> >It does not seem new OO API will do better job as it may have
> >completely
> >different method names and syntax.
>
Yes, that's why I like it. If someone new to PHP finds a tutorial using
"in_array($foo, $bar)", and one using "array_contains($bing, $bong)",
it's not obvious that these are two names for the same thing, and that
one is deprecated but backwards compatible, and the other is considered
"nicer", but only works in certain versions. Yes, if they check the
manual, they'll find out, but how do they know they need to check the
manual?
If, instead, they find the old tutorial using "in_array($foo, $bar)",
and the new one using "$foo->contains($bar)", they might notice that
there is a different *style* of code going on, and wonder what that's
about. They will then probable find a lot of people talking about
"procedural-style vs OO-style" or similar, and get a hint as to the pros
and cons of each.
> That's actually the advantage of an OO-style API - it's really
> obvious which set of functions someone else is using, and really
> easy to look at the two side by side.
>
> Users will not spend their time cross-referencing every function
> they see in a tutorial against the manual to see if it's been
> renamed with some extra underscores, and whether the new name has
> a different parameter order or error behaviour. But they might
> well read an article on how in version X, you can write things
> with this different syntax, and they'd instantly see that the old
> tutorial they found wasn't using that syntax.
>
>
> We have ArrayObject.
> http://php.net/manual/en/class.arrayobject.php
> I'm not a supporter of this class. Both class name and methods are not
> good enough. Implementation seems complex overly.
>
> It sounds like you are going to oppose to have improved array classes
> and/or array variable OO extension for the same reason.
>
> - Do you oppose to have better array class alternatives because of
> ArrayObject?
> - Do you think we must stick to this class/methods because it's
> already been here for a long time?
> - Do you oppose to have array variable object, i.e.
> $var_array->sort(), because we have ArrayObject already?
> - Do you agree if I object to have new/better OO API by existence of
> ArrayObject?
No, no, no, and no. ArrayObject is a rarely-used class allowing users to
have something that's halfway between an array and an object. It was
introduced in PHP 5, but only guaranteed to be available in PHP 5.3
(because distributions could disable the SPL extension by default before
that); the majority of users of PHP have probably never heard of it. It
also can't, and isn't intended to, replace the normal array type, which
is incredibly flexible, and at the heart of many parts of PHP.
Contrast that to, say, `in_array()`, which has been around for at least 15
years, probably more, and is probably used in about 90% of PHP scripts
written in that time, including thousands which are still maintained, or
publically available to be used as examples by new programmers. Any
argument treating the two as equivalent is a straw man.
>
> >> The paragraph you are replying to says "new API". It does not say
> >"pure
> >> OO". As I've said before, the relevance of scalar methods is
> not that
> >> objects are cool and functions are boring; it's that they're
> >something new
> >> we can design from scratch without worrying about the 20 years of
> >legacy
> >> the existing API has.
> >>
> >
> >I'm against making procedural API legacy so that someone would not
> >propose
> >
> >"Let's discard legacy, messy and inconsistent procedural API at all"
>
>
> Again, you bring it back to the assumption that "new API" means
> "not procedural any more". I'm not sure how many different ways I
> can find of saying that's not the point.
>
>
> I thought you prefer to have scalar object (including array) rather
> than procedural API fix/improvement. I'm lost here. So how would you
> like to fix naming mess and parameter miss ordering issue in
> procedural APIs? Leave inconsistent procedural functions forever?
As I have said repeatedly, I prefer to have some kind of brand new API,
so that it is really obvious to users that they are using "the new API"
or "the old API", rather than a bunch of minor variations which you can
only learn by studying the manual and remembering which is which. Adding
methods on scalars and arrays (which doesn't necessarily mean making
them objects in any meaningful way) is just a way of achieving that
goal. If someone comes up with a procedural API that feels new and
fresh, I'm all for it; a few changes to the existing API, I'm against.
>
> It's not that it doesn't do enough to keep the API around -
> frankly, I can't see those functions going away whatever happens.
> It's that it doesn't do enough for people to want to start using
> the new functions. Who is going to bother replacing all their
> instances of in_array with array_in?
>
>
> I agree that old functions should be able to use. Old name aliases
> should stay forever. Users do not have to rewrite their code with this
> RFC. They can use old names as long as they wish. Old codes are not
> invalid code, but perfectly valid code.
But if nobody adopts the new functions, all your effort will have been
in vain. If every PHP script was written in complete isolation, used for
a while, and thrown away, a free choice makes sense. But old code
*evolves* into new code, and now more than ever, PHP has an eco-system
of interoperable shared libraries, and people need to be able to read
and contribute to each other's code. For any new names or API to be
successful at all, people have got to WANT to change their code.
> So your idea is to leaving behind procedural API inconsistencies
> forever and keep as it is?
Either we leave it as it is, because we don't have the time machine
required for the proper fix, or we come up with a creative solution to
the problem, rather than making a few confusing changes.
>
> I used to really like the idea of a namespace with all the new
> functions in, and indeed the bulk import/default namespace idea,
> but I realised it doesn't really help. You have zero BC, but you
> also have a language which is incredibly hard to read, because the
> same line of code will do different things based on whether the
> file begins with a particular "use" statement. And now, rather
> than being confused about whether array_key_exists takes needle
> first or second, users have to be confused that it sometimes works
> one way, and sometimes the other, depending on which namespace
> they're operating in.
>
>
> I agree. Flexibility comes with its cost. It's possible to write
> incredibly hard to read code with Ruby/JavaScript/Scheme/etc.
> This is one of the reason why I didn't propose "namespace" use.
> Keeping RFC simple is better to discuss targeted issue.
It's not that namespaces would make code hard to read as such. What
would make code hard to read would be having the same function work
differently depending on a setting at the top of the file. You'd be
replacing one kind of inconsistency with another.
>
> Even without such feature, we may do
>
> PHP FizzBuzz http://3v4l.org/KFRj6
> <? $_ = ("@]@@]@"^"#/%!)%")._.("@]@@]@@@"^"&(.#))/.");
> $__=$_('$__,$____','
> $_ = !"";
> $$_ = +"";
> $___ = $_ + $_ + $_;
> $_____ = $___+$_+$_;
> $$$_ ="|@@@"^":)::";
> $$$$_ = "|]@@"^">(::";
> $$___ = "]]).]:"^"-/@@)\\\";
> $$___(($__%($_ .
> $_____)?$__%$_____?$__%$___?$__:$$$_:$$$$_:$$$_.$$$$_)."
> ");
> $__- ($_ . $$_ . $$_) && $____($__+!"",$____); ');
> $__(!'',$__);
I have no idea what this has to do with anything.
>
> I mean that you are approaching this with the enthusiasm of
> someone bringing a new idea to the table, and trying to win over
> people who've been working on the prioject for years. But the fact
> is that this conversation has been had before, many times over,
> and it has never been adopted before. You have very little chance
> of getting it adopted this time.
>
>
> You are probably right.
> There were roughly 4 groups of people.
>
> 1. Inconsistent/legacy procedural API must be replaced by new/better
> OO API
> 2. Do not care consistency and keep it as it is now.
> 3. Some current names are good enough and should not be removed.
> (e.g. IEEE/C lib based names)
> 4. Consistent naming is important.
>
> 1, 2 and 3 are majority. I added IEEE/lib names as a part of PHP
> standard names.
> There will be more supporters hopefully, but it seems it's not enough.
I would re-word point 1 as "...replaced by new/better API, probably OO
or OO-like". The emphasis is on the new, not the OO, IMHO.
> There may be such people, yes. But they are not your main problem
> in getting your proposal adopted. Your main problem are two groups:
> - those who think it is far too late to change any of this, and
> that it's just not worth the hassle for a few minor annoyances
> - those who think that it might be justifiable if we can find a
> way of making a compelling new set of functions, rather than just
> tweaking a few corner cases
>
>
> Thank you for the analysis. It's reasonable one. I should think how to
> persuade them.
>
> Changes are never too late! Especially non destructive change like
> this RFC.
Sometimes it really is too late to change something; it's too late to
decide that we don't want $ in front of variables, for instance, not
because it's not a "good" change, but because it would cause huge
disruption, so could only be justified by an even bigger benefit.
"Non destructive" makes it sound like there is no cost; as I have
repeatedly explained, it does have a cost.
> >The reason why previous proposals have failed is aggressive OO
>
> >supporter
> >rejected "procedural API improvement", isn't it?
>
>
> No. That is a relatively recent phenomenon, if it's real at all.
> The reason previous proposals have failed is that people think the
> costs outweigh the benefits.
>
>
> I saw many "There should be better OO API for them and use them" for
> PHP5 discussion also.
>
> I don't understand the reasoning "costs outweigh the benefits". It
> sounds like excuse for promoting OO API for me. Use of new OO API
> requires new codes/manuals. It's more than aliasing. Cost of having
> new name disappears over time while cost of having inconsistent names
> accumulate.
I don't know what's hard to understand about comparing costs and
benefits. Yes, there are benefits to having consistent names; we all
agree on that. What we disagree on is the cost of achieving that. It's
not an "excuse for promoting" anything; it's just a difference of
opinion about how enthusiastically everyone will adopt the new names and
thus erode the cost of having both names in use.
> >Let's see how it goes by vote. This vote is going to be whether we'll
> >take
> >direction to pure OO or multi-paradigm.
>
>
> No, the only vote we can have right now is on the option on the
> table, so will be whether it's worth the pain to change things
> which have worked this way for twenty years. There is no proposal
> on the table for making PHP an OO only language, and I'm not even
> sure what such a proposal would look like at this point in time.
>
> PHP is not in imminent danger of death if we leave a handful of
> string and array functions with slightly awkward names and
> behaviour, so it's not like we've got to choose between two rescue
> plans, messing with the functions or jumping into OO.
>
> I get that you find those functions annoying, but not everyone
> agrees with you. Maybe I'm wrong and there's a silent majority
> willing to push this through, but I would be extremely surprised
> if a vote on this was anything other than a landslide "no thanks".
>
>
> Again. This RFC is not a destructive RFC at all. Good changes are
> never too late. Almost all languages does this kind of
> maintenance/improvement, even destructive changes like dropping old
> syntax/etc.
>
> Unless one is not willing to replace/eliminate legacy and messy
> procedural API, I don't understand the reasoning to object to have
> consistent names. It's new consistent names that can be used
> optionally. Old names are available probably forever.
If after this many e-mails, you really don't understand why, as a matter
of opinion, people think this proposal is too costly, I really don't
know what more I or anyone can say to explain it to you.
> I do rename for my codes to keep it consistent all the time. We do
> rename PHP internal code to keep it nice and consistent on occasions.
> I fail to see why not PHP functions, why not giving users a chance to
> use nice and consistent names if users would like to.
>
> Anyway, your opinions to summarize:
> - User should use new/better OO API. (And we should focus new OO API
> development)
> - Inconsistent names should be kept forever.
> - This RFC requires existing manual/code rewrites. Therefore, this
> RFC does not worth to adopt.
>
> Is this correct? I find a little contradictory opinions here... We
> need completely new manuals/codes for new OO API while this RFC does not.
Not quite; my opinions are more like this:
- Inconsistent names of core functions are here to stay whether we like
it or not.
- If we want to create an alternative, it needs to be something radical.
An OO-style API seems the best candidate for that so far suggested.
- This RFC doesn't give existing users any incentive to rewrite all
their code with the new names, but will leave new users even more
confused because they won't know why all the functions have two names,
and why some code uses one and some uses the other. Therefore, it
creates more problems than it solves.
Regards,
--
Rowan Collins
[IMSoP]
wrote:
>
>
>> Hi Rowan,
>>
>> On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins
>>
>> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki
>> >Hi Rowan,
>> >
>> >On Fri, Mar 6, 2015 at 5:41 AM, Rowan Collins
>>
>> >wrote:
>> >
>> >> Yasuo Ohgaki wrote on 05/03/2015 20:20:
>> >>
>> >>> Hi Arvids,
>> >>>
>> >>> On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks
>> >
>> >>>
>> >>>
>> >>> 2015-03-05 13:49 GMT+02:00 Pierre Joye
>>
>> >>>
>> >>> >
>> >>> >
>> >>> > I will say it again a last time, in my opinion only a clean
>> >API;
>> >>> > object-like or real object as long as performance is not
>> >affected is
>> >>> > the only way I could see to actually solve this problem.
>> >>> >
>> >>> > Changing the names, argument order (pointless once we will
>> >have
>> >>> named
>> >>> > arguments, btw) and similar solutions are band aids
>> solutions,
>> >>> > confusing at best, terrible at worst. It is pointless to
>> do it
>> >after
>> >>> > almost two decades for some of them.
>> >>> >
>> >>> > --
>> >>> > Pierre
>> >>> >
>> >>> > I'm with Pierre here.
>> >>> Adding aliases is gonna mess up things even more. For
>> example -
>> >>> autocomplete will become hard to navigate. It's already quite
>> >>> lengthy list
>> >>> a lot of the times and it's easier just to write the whole
>> >>> function name
>> >>> sometimes by hand. Adding aliases will make it worse.
>> >>>
>> >>>
>> >>> I agree. Therefore, I'm going to update manual also so that it
>> >recommends
>> >>> main function, not aliases. Aliases should be alternative.
>> >>>
>> >>> Manual and IDE don't have to list all of them. New manual
>> lists only
>> >main
>> >>> functions, does not have dedicated pages for aliases but
>> aliases are
>> >>> mentioned
>> >>> in main function page as aliases.
>> >>>
>> >>
>> >>
>> >> You can't fix everyone's IDEs for them. You can't fix all the
>> >> documentation (tutorials, blogs, Q&As) not hosted on php.net
>>
>> >> all, you can't fix the thousands of projects already written in PHP
>> >using
>> >> the "wrong" function names, most of which will want to *continue*
>> >using
>> >> those function names, because that will be internally
>> consistent, and
>> >> portable between versions.
>> >>
>> >> The problems people are pointing out are not ones that you can
>> >promise to
>> >> fix.
>> >>
>> >
>> >The same argument applies to OO API alternative.
>> >It's impossible update documents/etc to use new OO API as you
>> >mentioned.
>>
>>
>
> To an extent, yes. Part of the point that I and others are making is that
> this is not a simple change to make. Whatever we do to try and "fix" the
> current inconsistencies comes at a cost, and we need to be very careful in
> justifying that cost.
>
I agree. You are right.
The cost of introducing new names disappears over time. The cost of having
inconsistent name accumulates.
>
>
> >
>> >My proposal only requires simple replace. Even simple replace
>> would not
>> >be
>> >needed since old names work as should be. Users can know what's the
>> >main
>> >function by looking up manual.
>>
>>
>
> You have to do at least a bit of code parsing, because you wouldn't want
> to change things like echo 'Your site has exploded!'; or function
> check_blob_is_in_array_twice() { ... }
>
> So this really comes to the same thing whatever changes we make - people
> can either run a converter tool over their code (and create some noise in
> the version control history) or you carry on using the old functions and
> get no benefit from the change.
>
Only because old names/parameter order is inconsistent, making old function
names deprecated/removed is not a good idea. IMO. It should be available as
valid/official name/function for a long time if it is ever
removed/deprecated.
>
>
> >It does not seem new OO API will do better job as it may have
>> >completely
>> >different method names and syntax.
>>
>>
>
> Yes, that's why I like it. If someone new to PHP finds a tutorial using
> "in_array($foo, $bar)", and one using "array_contains($bing, $bong)", it's
> not obvious that these are two names for the same thing, and that one is
> deprecated but backwards compatible, and the other is considered "nicer",
> but only works in certain versions. Yes, if they check the manual, they'll
> find out, but how do they know they need to check the manual?
>
> If, instead, they find the old tutorial using "in_array($foo, $bar)", and
> the new one using "$foo->contains($bar)", they might notice that there is a
> different *style* of code going on, and wonder what that's about. They will
> then probable find a lot of people talking about "procedural-style vs
> OO-style" or similar, and get a hint as to the pros and cons of each.
>
> That's actually the advantage of an OO-style API - it's really
>> obvious which set of functions someone else is using, and really
>> easy to look at the two side by side.
>>
>> Users will not spend their time cross-referencing every function
>> they see in a tutorial against the manual to see if it's been
>> renamed with some extra underscores, and whether the new name has
>> a different parameter order or error behaviour. But they might
>> well read an article on how in version X, you can write things
>> with this different syntax, and they'd instantly see that the old
>> tutorial they found wasn't using that syntax.
>>
>>
>> We have ArrayObject.
>> http://php.net/manual/en/class.arrayobject.php
>> I'm not a supporter of this class. Both class name and methods are not
>> good enough. Implementation seems complex overly.
>>
>> It sounds like you are going to oppose to have improved array classes
>> and/or array variable OO extension for the same reason.
>>
>> - Do you oppose to have better array class alternatives because of
>> ArrayObject?
>> - Do you think we must stick to this class/methods because it's already
>> been here for a long time?
>> - Do you oppose to have array variable object, i.e. $var_array->sort(),
>> because we have ArrayObject already?
>> - Do you agree if I object to have new/better OO API by existence of
>> ArrayObject?
>>
>
>
> No, no, no, and no. ArrayObject is a rarely-used class allowing users to
> have something that's halfway between an array and an object. It was
> introduced in PHP 5, but only guaranteed to be available in PHP 5.3
> (because distributions could disable the SPL extension by default before
> that); the majority of users of PHP have probably never heard of it. It
> also can't, and isn't intended to, replace the normal array type, which is
> incredibly flexible, and at the heart of many parts of PHP.
>
Then we may be better to declare deprecation of ArrayObject now.
>
> Contrast that to, say, `in_array()`, which has been around for at least 15
> years, probably more, and is probably used in about 90% of PHP scripts
> written in that time, including thousands which are still maintained, or
> publically available to be used as examples by new programmers. Any
> argument treating the two as equivalent is a straw man.
>
I agree that there will be confusions in short term. We have very fast
release cycle, PHP 5.6 is only supported for 3 years from now. Instead of
measuring cost of short term, long term cost that accumulates should be
considered.
PHP will introduce new way of programming, including OO, why do you care
much about 3rd party documents? They have to rewrite documents for new PHP
anyway.
Old functions should remain forever or very long term unless there is very
good reasons to deprecate/remove. Users don't have to rewrite code only for
new names.
>
>
>> >> The paragraph you are replying to says "new API". It does not say
>> >"pure
>> >> OO". As I've said before, the relevance of scalar methods is
>> not that
>> >> objects are cool and functions are boring; it's that they're
>> >something new
>> >> we can design from scratch without worrying about the 20 years of
>> >legacy
>> >> the existing API has.
>> >>
>> >
>> >I'm against making procedural API legacy so that someone would not
>> >propose
>> >
>> >"Let's discard legacy, messy and inconsistent procedural API at all"
>>
>>
>> Again, you bring it back to the assumption that "new API" means
>> "not procedural any more". I'm not sure how many different ways I
>> can find of saying that's not the point.
>>
>>
>> I thought you prefer to have scalar object (including array) rather than
>> procedural API fix/improvement. I'm lost here. So how would you like to fix
>> naming mess and parameter miss ordering issue in procedural APIs? Leave
>> inconsistent procedural functions forever?
>>
>
>
> As I have said repeatedly, I prefer to have some kind of brand new API, so
> that it is really obvious to users that they are using "the new API" or
> "the old API", rather than a bunch of minor variations which you can only
> learn by studying the manual and remembering which is which. Adding methods
> on scalars and arrays (which doesn't necessarily mean making them objects
> in any meaningful way) is just a way of achieving that goal. If someone
> comes up with a procedural API that feels new and fresh, I'm all for it; a
> few changes to the existing API, I'm against.
>
The change is about "consistency". Many users complain about it for a long
time. New API should have consistent API as well as old API, IMHO.
We keep procedural APIs forever, right? Why not clean it up? Older PHP
became unmaintained version in 2 years after new PHP release. I think it's
short.
>
>> It's not that it doesn't do enough to keep the API around -
>> frankly, I can't see those functions going away whatever happens.
>> It's that it doesn't do enough for people to want to start using
>> the new functions. Who is going to bother replacing all their
>> instances of in_array with array_in?
>>
>>
>> I agree that old functions should be able to use. Old name aliases should
>> stay forever. Users do not have to rewrite their code with this RFC. They
>> can use old names as long as they wish. Old codes are not invalid code, but
>> perfectly valid code.
>>
>
>
> But if nobody adopts the new functions, all your effort will have been in
> vain. If every PHP script was written in complete isolation, used for a
> while, and thrown away, a free choice makes sense. But old code *evolves*
> into new code, and now more than ever, PHP has an eco-system of
> interoperable shared libraries, and people need to be able to read and
> contribute to each other's code. For any new names or API to be successful
> at all, people have got to WANT to change their code.
>
Users don't have to rush into new names. It's OK for not adopting new names
in short term at all. Old names/functions are valid names/functions. I
think it is enough if users use new names mostly decades later.
>
>
> So your idea is to leaving behind procedural API inconsistencies forever
>> and keep as it is?
>>
>
>
> Either we leave it as it is, because we don't have the time machine
> required for the proper fix, or we come up with a creative solution to the
> problem, rather than making a few confusing changes.
>
We have very short release cycle. 2 years later after new release, old PHP
became obsolete. Distributors maintains older PHPs, it's users choice to
write compatible code and how to write compatible code will be documented
well in our manual, as well as how to write new OO API for new PHPs.
>
>> I used to really like the idea of a namespace with all the new
>> functions in, and indeed the bulk import/default namespace idea,
>> but I realised it doesn't really help. You have zero BC, but you
>> also have a language which is incredibly hard to read, because the
>> same line of code will do different things based on whether the
>> file begins with a particular "use" statement. And now, rather
>> than being confused about whether array_key_exists takes needle
>> first or second, users have to be confused that it sometimes works
>> one way, and sometimes the other, depending on which namespace
>> they're operating in.
>>
>>
>> I agree. Flexibility comes with its cost. It's possible to write
>> incredibly hard to read code with Ruby/JavaScript/Scheme/etc.
>> This is one of the reason why I didn't propose "namespace" use. Keeping
>> RFC simple is better to discuss targeted issue.
>>
>
>
> It's not that namespaces would make code hard to read as such. What would
> make code hard to read would be having the same function work differently
> depending on a setting at the top of the file. You'd be replacing one kind
> of inconsistency with another.
>
Many languages support creating whole new function/class names including
PHP. We can have `strlen()` which returns string length rather than bytes
with current namespace. To find out what really happens on function call,
we need to check "namespace". I don't see much difference between default
namespace by INI and namespace used in script. Both are the declaration of
namespace to be used.
I agree that adding place to look will be additional work.
>
>
>
>> Even without such feature, we may do
>>
>> PHP FizzBuzz http://3v4l.org/KFRj6
>> <? $_ = ("@]@@]@"^"#/%!)%")._.("@]@@]@@@"^"&(.#))/.");
>> $__=$_('$__,$____','
>> $_ = !"";
>> $_ = +"";
>> $___ = $_ + $_ + $_;
>> $_____ = $___+$_+$_;
>> $$_ ="|@@@"^":)::";
>> $$_ = "|]@@"^">(::";
>> $___ = "]]).]:"^"-/@@)\\\";
>> $___(($__%($_ . $_____)?$__%$_____?$__%$___?$__:$$_:$$_:$$_.$$_)."
>> ");
>> $__- ($_ . $_ . $_) && $____($__+!"",$____); ');
>> $__(!'',$__);
>>
>
>
> I have no idea what this has to do with anything.
>
Just an example that PHP allows to write extremely hard to read code
already.
>
>
>
>> I mean that you are approaching this with the enthusiasm of
>> someone bringing a new idea to the table, and trying to win over
>> people who've been working on the prioject for years. But the fact
>> is that this conversation has been had before, many times over,
>> and it has never been adopted before. You have very little chance
>> of getting it adopted this time.
>>
>>
>> You are probably right.
>> There were roughly 4 groups of people.
>>
>> 1. Inconsistent/legacy procedural API must be replaced by new/better OO
>> API
>> 2. Do not care consistency and keep it as it is now.
>> 3. Some current names are good enough and should not be removed. (e.g.
>> IEEE/C lib based names)
>> 4. Consistent naming is important.
>>
>> 1, 2 and 3 are majority. I added IEEE/lib names as a part of PHP standard
>> names.
>> There will be more supporters hopefully, but it seems it's not enough.
>>
>
>
> I would re-word point 1 as "...replaced by new/better API, probably OO or
> OO-like". The emphasis is on the new, not the OO, IMHO.
>
I think this is the root of our opinion differences.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO like API
if it's possible.
>
>
> There may be such people, yes. But they are not your main problem
>> in getting your proposal adopted. Your main problem are two groups:
>> - those who think it is far too late to change any of this, and
>> that it's just not worth the hassle for a few minor annoyances
>> - those who think that it might be justifiable if we can find a
>> way of making a compelling new set of functions, rather than just
>> tweaking a few corner cases
>>
>>
>> Thank you for the analysis. It's reasonable one. I should think how to
>> persuade them.
>>
>> Changes are never too late! Especially non destructive change like this
>> RFC.
>>
>
> Sometimes it really is too late to change something; it's too late to
> decide that we don't want $ in front of variables, for instance, not
> because it's not a "good" change, but because it would cause huge
> disruption, so could only be justified by an even bigger benefit.
>
> "Non destructive" makes it sound like there is no cost; as I have
> repeatedly explained, it does have a cost.
>
Introduction of consistency has it costs. I wouldn't deny it even if it's
short term costs.
However, keeping inconsistency has it costs also. It's long term costs that
never disappears as long as it exists.
It's obvious choice for me...
> >The reason why previous proposals have failed is aggressive OO
>>
>> >supporter
>> >rejected "procedural API improvement", isn't it?
>>
>>
>> No. That is a relatively recent phenomenon, if it's real at all.
>> The reason previous proposals have failed is that people think the
>> costs outweigh the benefits.
>>
>>
>> I saw many "There should be better OO API for them and use them" for PHP5
>> discussion also.
>>
>> I don't understand the reasoning "costs outweigh the benefits". It sounds
>> like excuse for promoting OO API for me. Use of new OO API requires new
>> codes/manuals. It's more than aliasing. Cost of having new name disappears
>> over time while cost of having inconsistent names accumulate.
>>
>
>
> I don't know what's hard to understand about comparing costs and benefits.
> Yes, there are benefits to having consistent names; we all agree on that.
> What we disagree on is the cost of achieving that. It's not an "excuse for
> promoting" anything; it's just a difference of opinion about how
> enthusiastically everyone will adopt the new names and thus erode the cost
> of having both names in use.
>
>
> >Let's see how it goes by vote. This vote is going to be whether we'll
>> >take
>> >direction to pure OO or multi-paradigm.
>>
>>
>> No, the only vote we can have right now is on the option on the
>> table, so will be whether it's worth the pain to change things
>> which have worked this way for twenty years. There is no proposal
>> on the table for making PHP an OO only language, and I'm not even
>> sure what such a proposal would look like at this point in time.
>>
>> PHP is not in imminent danger of death if we leave a handful of
>> string and array functions with slightly awkward names and
>> behaviour, so it's not like we've got to choose between two rescue
>> plans, messing with the functions or jumping into OO.
>>
>> I get that you find those functions annoying, but not everyone
>> agrees with you. Maybe I'm wrong and there's a silent majority
>> willing to push this through, but I would be extremely surprised
>> if a vote on this was anything other than a landslide "no thanks".
>>
>>
>> Again. This RFC is not a destructive RFC at all. Good changes are never
>> too late. Almost all languages does this kind of maintenance/improvement,
>> even destructive changes like dropping old syntax/etc.
>>
>> Unless one is not willing to replace/eliminate legacy and messy
>> procedural API, I don't understand the reasoning to object to have
>> consistent names. It's new consistent names that can be used optionally.
>> Old names are available probably forever.
>>
>
>
> If after this many e-mails, you really don't understand why, as a matter
> of opinion, people think this proposal is too costly, I really don't know
> what more I or anyone can say to explain it to you.
>
Let's agree to disagree. Otherwise, discussion will be circular.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO like API
if it's possible.
I estimate cost of inconsistency is long term and huge.
You estimate introduction cost of consistent names is huge, even if it's
short term cost disappears over time.
I don't think users have to rewrite their existing code at all, so
no/little confusions.
You think users will try to rewrite their existing code, and there is
confusions.
I know there are unhappy users that PHP has inconsistent procedural
functions and I would like to do something for them.
You think those unhappy users should adopt new/better APIs and forget about
inconsistency.
There are some more, but these are main points from my point of view.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Let's agree to disagree. Otherwise, discussion will be circular.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO like API
if it's possible.
Discussions like this need to be on two levels.
Creating a clean OO based API is like unicode, one of those things 
everybody wants, but no one has come up with the ideal solution to take 
it forward? I'd even include PDO in that 'debate' as it blocks actions 
that the procedural interface can currently provide so the main 
development is still on the generic drivers. But the current array 
objects are not gaining traction either?
Removing the procedural interface is certainly the point where I would 
simply stop upgrading and switch to maintaining an older version. It's 
no secret that I wish I had stepped in and carried on with security 
updates to PHP5.2 ... it still runs a lot of sites without any problems!
'Fixing' the procedural interface is something somewhat borderline, 
which is why I asked 'what is the coding standard?' If the main track 
going forward IS to push a fully OO API as the main interface, then the 
need for making changes to the procedural interface is lessened? Only if 
the primary interface is to remain procedural is the debate on 
consistent function names relevant. So I'd prefer pushing that 'problem' 
to an OO API and being a lot lighter on ANY of the changes to the 
current function set, and simply maintain it as is.
I'm 60 this year so that does determine some of my choices, and at the 
moment PHP (along with windows) is a tiring slog of trying to upgrade 
rather than the pleasure that was 10 years ago when freed from the 
straight jacket of 'C++'. Everybody seems intent on reimposing the 
straight jacket of strict types and constrained error handling :(
-- 
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
On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:To an extent, yes. Part of the point that I and others are making is that this is not a simple change to make. Whatever we do to try and "fix" the current inconsistencies comes at a cost, and we need to be very careful in justifying that cost.I agree. You are right.
The cost of introducing new names disappears over time. The cost of
having inconsistent name accumulates.
You've said this a couple of times, but I'm not sure what you mean. What 
is the cost which is accumulating in the current situation, and how will 
your proposal stop or reverse this accumulation?
>My proposal only requires simple replace. [...] You have to do at least a bit of code parsing, because you wouldn't want to change things like echo 'Your site has exploded!'; or function check_blob_is_in_array_twice() { ... }Only because old names/parameter order is inconsistent, making old
function names deprecated/removed is not a good idea. IMO. It should
be available as valid/official name/function for a long time if it is
ever removed/deprecated.
Can you please try to respond to the actual points I make, rather than 
repeating the same ones? You said changing names would be a "simple 
replace"; I pointed out that it would be more complicated than that 
(automatable, but not as trivial as find-and-replace in a text editor). 
This has nothing to do with parameter order, and nothing to do with the 
old names being removed - just that, if people want to make use of your 
new function names, they will need a tool to update their code.
No, no, no, and no. ArrayObject is a rarely-used class allowing users to have something that's halfway between an array and an object. It was introduced in PHP 5, but only guaranteed to be available in PHP 5.3 (because distributions could disable the SPL extension by default before that); the majority of users of PHP have probably never heard of it. It also can't, and isn't intended to, replace the normal array type, which is incredibly flexible, and at the heart of many parts of PHP.Then we may be better to declare deprecation of ArrayObject now.
No, because it probably still has its uses, and nobody is being 
encouraged to use it in a way that will interfere with our ability to 
create "scalar methods" later.
An important point you may have missed is that some of the proposals 
around methods on scalar values don't really propose turning the values 
into objects, just adding some syntactic sugar to the language so that 
'foo'->toUppercase() is a way of writing strtoupper('foo').
Contrast that to, say, `in_array()`, which has been around for at least 15 years, probably more, and is probably used in about 90% of PHP scripts written in that time, including thousands which are still maintained, or publically available to be used as examples by new programmers. Any argument treating the two as equivalent is a straw man.I agree that there will be confusions in short term. We have very fast
release cycle, PHP 5.6 is only supported for 3 years from now.
If only it were true that "not supported" meant "nobody cares about". 
AFAIK, Wordpress is still actively supporting PHP 5.2, which has been 
unsupported for over 4 years already. The time scale you need to worry 
about is how long until people start using your new names, and how long 
after that until they use the old ones rarely enough that people don't 
need to learn them anyway.
PHP will introduce new way of programming, including OO, why do you
care much about 3rd party documents? They have to rewrite documents
for new PHP anyway.
Why do I care about third parties? Because they are the backbone of the 
language. The language is not you and me debating its future on a single 
mailing list, it's thousands of people all over the world actually using it.
As I have said repeatedly, I prefer to have some kind of brand new API, so that it is really obvious to users that they are using "the new API" or "the old API", rather than a bunch of minor variations which you can only learn by studying the manual and remembering which is which. Adding methods on scalars and arrays (which doesn't necessarily mean making them objects in any meaningful way) is just a way of achieving that goal. If someone comes up with a procedural API that feels new and fresh, I'm all for it; a few changes to the existing API, I'm against.The change is about "consistency". Many users complain about it for a
long time. New API should have consistent API as well as old API, IMHO.
But the old API already isn't consistent, and unless you remove all the 
current function names, it will never be consistent, because those 
names will be there, inconsistently.
But if nobody adopts the new functions, all your effort will have been in vain. If every PHP script was written in complete isolation, used for a while, and thrown away, a free choice makes sense. But old code *evolves* into new code, and now more than ever, PHP has an eco-system of interoperable shared libraries, and people need to be able to read and contribute to each other's code. For any new names or API to be successful at all, people have got to WANT to change their code.Users don't have to rush into new names. It's OK for not adopting new
names in short term at all. Old names/functions are valid
names/functions. I think it is enough if users use new names mostly
decades later.
This is basically the reasoning that led to the Y2K bug: "if we wait 
long enough, people won't be looking at this old code, they'll have 
replaced it all. It turns out, code tends to proceed by evolution not 
revolution, so however long you wait, there will still be the same 
reasons not to switch over to the new names.
It's not that namespaces would make code hard to read as such. What would make code hard to read would be having the same function work differently depending on a setting at the top of the file. You'd be replacing one kind of inconsistency with another.Many languages support creating whole new function/class names
including PHP. We can havestrlen()which returns string length rather
than bytes with current namespace. To find out what really happens on
function call, we need to check "namespace". I don't see much
difference between default namespace by INI and namespace used in
script. Both are the declaration of namespace to be used.I agree that adding place to look will be additional work.
Yes, it's not so much that it's not possible right now, as that it's 
not explicitly encouraged. If the authors of Symfony decided they were 
going to write a function called Symfony\replacement\strlen and "use 
function" it at the top of every file in their distributed code and 
coding guidelines, it would not be a popular move. Using namespace 
imports to alter behaviour as a hack around BC concerns means explicitly 
encouraging people to do something that makes their code harder to read.
I would re-word point 1 as "...replaced by new/better API, probably OO or OO-like". The emphasis is on the new, not the OO, IMHO.I think this is the root of our opinion differences.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO
like API if it's possible.
I'm going to say this one more time, and in a very short sentence, in 
the hope that you'll actually understand/believe me:
I do not see it as a choice between OO and procedural API.
I estimate cost of inconsistency is long term and huge.
You estimate introduction cost of consistent names is huge, even if
it's short term cost disappears over time.
I estimate that the cost of introducing new names if fairly large, and 
fairly long-term.
I also take from the phenomenal success of PHP over the last twenty 
years the knowledge that the cost of the inconsistency is not 
cripplingly large.
I don't think users have to rewrite their existing code at all, so
no/little confusions.
You think users will try to rewrite their existing code, and there is
confusions.
No, I think users won't rewrite their existing code, but since they 
won't, the new functions will simply be unused aliases, and the old 
functions will remain the de facto "real" names.
More specifically, this is what I see happening if your proposal passes:
- Existing projects, both public and private, will debate whether to 
 convert their code to the new names. Most will see little benefit in
 doing so. Many will maintain compatibility with extremely old versions
 of PHP, and be basically unable to do so.
- Coding standards will be forced to choose which names to use; because 
 it's not obvious looking at a name whether it's "old", "new", or
 "unchanged", they will have to create whole lists of banned function names.
- PHP-FIG will debate things at great length, and come to a conclusion 
 that not everyone likes, causing friction in the community.
- New contributors will submit patches using the new names to projects 
 whose policies require the old names, and be confused by the comments
 they get back.
- New developers will read through eixsting tutorials and code, 
 including cutting-edge code written to the above standards, and still
 see the same inconsistencies they see now.
- Small projects will adopt the new names, forcing developers to learn 
 both. People used to only the new names will keep having to check the
 manual to be sure the functions are actually just aliases.
- The people who like to find excuses to criticise PHP will look at the 
 situation, and say it proves how awful PHP is.
This is, I admit, a pessimistic scenario. But the worst case scenario 
for not changing the names appears to be "people will carry on using 
PHP, but be a bit annoyed at the naming inconsistencies occasionally, 
and maybe write blog posts about it; some people will be annoyed enough 
to choose a different language". Do you have a different worst case 
scenario that makes you so keen to change the names?
Regards,
-- 
Rowan Collins 
[IMSoP]
Hi Rowan,
On Mon, Mar 9, 2015 at 7:42 AM, Rowan Collins rowan.collins@gmail.com 
wrote:
On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins <rowan.collins@gmail.com
mailto:rowan.collins@gmail.com> wrote:To an extent, yes. Part of the point that I and others are making is that this is not a simple change to make. Whatever we do to try and "fix" the current inconsistencies comes at a cost, and we need to be very careful in justifying that cost.I agree. You are right.
The cost of introducing new names disappears over time. The cost of
having inconsistent name accumulates.You've said this a couple of times, but I'm not sure what you mean. What
is the cost which is accumulating in the current situation, and how will
your proposal stop or reverse this accumulation?
By introducing consistent names. 
We have obvious cost for having inconsistent names. People complain/hate it 
for a long time in past and future. We don't have to reverse it, but make 
it disappears over time.
I understand your point of views that old inconsistent procedural API 
should be disappeared in the future. However, I cannot agree to make 
procedural API disappear.
>My proposal only requires simple replace. [...] You have to do at least a bit of code parsing, because you wouldn't want to change things like echo 'Your site has exploded!'; or function check_blob_is_in_array_twice() { ... }Only because old names/parameter order is inconsistent, making old
function names deprecated/removed is not a good idea. IMO. It should be
available as valid/official name/function for a long time if it is ever
removed/deprecated.Can you please try to respond to the actual points I make, rather than
repeating the same ones? You said changing names would be a "simple
replace"; I pointed out that it would be more complicated than that
(automatable, but not as trivial as find-and-replace in a text editor).
This has nothing to do with parameter order, and nothing to do with the old
names being removed - just that, if people want to make use of your new
function names, they will need a tool to update their code.
Users may use whichever tools they like. I use Perl one liner for this kind 
of simple search and replace, then check it by git diff. Besides, they 
don't have to change their code. They may keep using old names as long as 
they exist.
No, no, no, and no. ArrayObject is a rarely-used class allowingusers to have something that's halfway between an array and an object. It was introduced in PHP 5, but only guaranteed to be available in PHP 5.3 (because distributions could disable the SPL extension by default before that); the majority of users of PHP have probably never heard of it. It also can't, and isn't intended to, replace the normal array type, which is incredibly flexible, and at the heart of many parts of PHP.Then we may be better to declare deprecation of ArrayObject now.
No, because it probably still has its uses, and nobody is being encouraged
to use it in a way that will interfere with our ability to create "scalar
methods" later.An important point you may have missed is that some of the proposals
around methods on scalar values don't really propose turning the values
into objects, just adding some syntactic sugar to the language so that
'foo'->toUppercase() is a way of writing strtoupper('foo').
You think legacy procedural should be gone and replaced by OO features 
preferably. Procedural API is used a lot of codes. I agree that ArrayObject 
is used by only few codes. Why against to declare legacy ArrayObject 
deprecation even we will have new OO API?
If things are going to be deprecated, we are better to let users know as 
soon as possible, then implement E_DEPRECATED error. Remove them if it's 
unneeded at all in the future.
Deprecation means removal in the future. We may at least let users know it 
will be obsolete in near future.
 Contrast that to, say, `in_array()`, which has been around for at
least 15 years, probably more, and is probably used in about 90% of PHP scripts written in that time, including thousands which are still maintained, or publically available to be used as examples by new programmers. Any argument treating the two as equivalent is a straw man.I agree that there will be confusions in short term. We have very fast
release cycle, PHP 5.6 is only supported for 3 years from now.If only it were true that "not supported" meant "nobody cares about".
AFAIK, Wordpress is still actively supporting PHP 5.2, which has been
unsupported for over 4 years already. The time scale you need to worry
about is how long until people start using your new names, and how long
after that until they use the old ones rarely enough that people don't need
to learn them anyway.
The same argument applies to fresh new OO APIs.
PHP will introduce new way of programming, including OO, why do you care
much about 3rd party documents? They have to rewrite documents for new PHP
anyway.Why do I care about third parties? Because they are the backbone of the
language. The language is not you and me debating its future on a single
mailing list, it's thousands of people all over the world actually using it.
My RFC is not going to depreciate/remove old inconsistent names. On the 
other hand, it makes most of standard violating names valid names 
officially.
I fail to see what's wrong for 3rd party document with it.
As I have said repeatedly, I prefer to have some kind of brand newAPI, so that it is really obvious to users that they are using "the new API" or "the old API", rather than a bunch of minor variations which you can only learn by studying the manual and remembering which is which. Adding methods on scalars and arrays (which doesn't necessarily mean making them objects in any meaningful way) is just a way of achieving that goal. If someone comes up with a procedural API that feels new and fresh, I'm all for it; a few changes to the existing API, I'm against.The change is about "consistency". Many users complain about it for a
long time. New API should have consistent API as well as old API, IMHO.But the old API already isn't consistent, and unless you remove all the
current function names, it will never be consistent, because those names
will be there, inconsistently.
I cannot agree "Because we have inconsistent names already, we cannot have 
new consistent names" argument.
What you are suggesting is not to have "is_writable()" because we have 
"is_writeable()" already.
http://php.net/manual/en/function.is-writable.php 
http://php.net/manual/en/function.is-writeable.php
or
http://php.net/manual/en/function.disk-free-space.php 
http://php.net/manual/en/function.diskfreespace.php
But if nobody adopts the new functions, all your effort will havebeen in vain. If every PHP script was written in complete isolation, used for a while, and thrown away, a free choice makes sense. But old code *evolves* into new code, and now more than ever, PHP has an eco-system of interoperable shared libraries, and people need to be able to read and contribute to each other's code. For any new names or API to be successful at all, people have got to WANT to change their code.Users don't have to rush into new names. It's OK for not adopting new
names in short term at all. Old names/functions are valid names/functions.
I think it is enough if users use new names mostly decades later.This is basically the reasoning that led to the Y2K bug: "if we wait long
enough, people won't be looking at this old code, they'll have replaced it
all. It turns out, code tends to proceed by evolution not revolution, so
however long you wait, there will still be the same reasons not to switch
over to the new names.
Again. This RFC make function names that are named after IEEE/C library 
valid names officially. I don't see any relevance with Y2K issue.
It's not that namespaces would make code hard to read as such.What would make code hard to read would be having the same function work differently depending on a setting at the top of the file. You'd be replacing one kind of inconsistency with another.Many languages support creating whole new function/class names including
PHP. We can havestrlen()which returns string length rather than bytes
with current namespace. To find out what really happens on function call,
we need to check "namespace". I don't see much difference between default
namespace by INI and namespace used in script. Both are the declaration of
namespace to be used.I agree that adding place to look will be additional work.
Yes, it's not so much that it's not possible right now, as that it's not
explicitly encouraged. If the authors of Symfony decided they were going
to write a function called Symfony\replacement\strlen and "use function" it
at the top of every file in their distributed code and coding guidelines,
it would not be a popular move. Using namespace imports to alter behaviour
as a hack around BC concerns means explicitly encouraging people to do
something that makes their code harder to read.
Feature to import namespace into default "" namespace is required not only 
for procedural API but also OO API to adopt namespace for internal 
functions/classes without any BC.
It's very important argument. We may discuss this when there is RFC.
 I would re-word point 1 as "...replaced by new/better API,
probably OO or OO-like". The emphasis is on the new, not the OO, IMHO.I think this is the root of our opinion differences.
I would like to keep/maintain legacy procedural functions forever.
You would like to replace/remove legacy procedural functions by OO like
API if it's possible.I'm going to say this one more time, and in a very short sentence, in the
hope that you'll actually understand/believe me:I do not see it as a choice between OO and procedural API.
You sounded like it, but I believe this words from now on.
I estimate cost of inconsistency is long term and huge.
You estimate introduction cost of consistent names is huge, even if it's
short term cost disappears over time.I estimate that the cost of introducing new names if fairly large, and
fairly long-term.
http://php.net/manual/en/function.is-writable.php 
http://php.net/manual/en/function.is-writeable.php
This kind of change should be adopted ASAP, IMHO. Name inconsistency is 
just like typo for me. i.e. Keeping it just damages things. Have corrected 
names and keep old names is the only way to have consistency.
I also take from the phenomenal success of PHP over the last twenty years
the knowledge that the cost of the inconsistency is not cripplingly large.
I don't think users have to rewrite their existing code at all, so
no/little confusions.
You think users will try to rewrite their existing code, and there is
confusions.No, I think users won't rewrite their existing code, but since they
won't, the new functions will simply be unused aliases, and the old
functions will remain the de facto "real" names.
Nothing wrong with it. User may use old names, it's valid names also.
More specifically, this is what I see happening if your proposal passes:
- Existing projects, both public and private, will debate whether to
convert their code to the new names. Most will see little benefit in doing
so. Many will maintain compatibility with extremely old versions of PHP,
and be basically unable to do so.- Coding standards will be forced to choose which names to use; because
it's not obvious looking at a name whether it's "old", "new", or
"unchanged", they will have to create whole lists of banned function names.- PHP-FIG will debate things at great length, and come to a conclusion
that not everyone likes, causing friction in the community.- New contributors will submit patches using the new names to projects
whose policies require the old names, and be confused by the comments they
get back.- New developers will read through eixsting tutorials and code, including
cutting-edge code written to the above standards, and still see the same
inconsistencies they see now.- Small projects will adopt the new names, forcing developers to learn
both. People used to only the new names will keep having to check the
manual to be sure the functions are actually just aliases.- The people who like to find excuses to criticise PHP will look at the
situation, and say it proves how awful PHP is.This is, I admit, a pessimistic scenario. But the worst case scenario for
not changing the names appears to be "people will carry on using PHP, but
be a bit annoyed at the naming inconsistencies occasionally, and maybe
write blog posts about it; some people will be annoyed enough to choose a
different language". Do you have a different worst case scenario that makes
you so keen to change the names?
The same argument applies to fresh new OO APIs. It's just a matter of 
targeted PHP version to be supported. There are many things to be 
considered to decide targeted PHP version other than this RFC. We have many 
new features/behaviors in newer PHP versions.
I'm OK for  "agree to disagree", too. However, since you are not willing to 
make procedural APIs obsolete/deprecate, why don't we agree to "maintain" 
procedural APIs?
Just like
http://php.net/manual/en/function.is-writable.php 
http://php.net/manual/en/function.is-writeable.php
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
The same argument applies to fresh new OO APIs. It's just a matter of
targeted PHP version to be supported. There are many things to be
considered to decide targeted PHP version other than this RFC. We have many
new features/behaviors in newer PHP versions.
I still have a major problem with the whole basis of your re-naming ... 
adding the underscore at all. It was this introduction which was totally 
wrong in the first place and I would rather rename the incorrectly 
renamed functions if only to make them consistent with what is used in 
the OO 'standard'.
$main->phpVersion() 
or 
phpversion()
Is consistent if one maintains the case insensitive rule.
Adding str_ in front of every string function where a lot are IEEE 
protected is just adding confusion. Where these map to an OO API in my book
strcmp() 
$str->cmp()
makes sense? 
Adding an extra $str_cmp is simply not necessary.
Simply dropping the poorly formulated 'add underscore' rule which only 
currently exists on the procedural interface and tidying up the mistake 
caused by that produces a MUCH shorter list of changes and allows much 
better consistency with even the existing OO interface elements?
I look at the 'tidy' gd interface and simply think 'what the ****'
Yes there are some inconsistent names, but in general 
imagecolorallocate 
and 
$image->colorAllocate
is more in keeping with the other graphics libraries.
YES there is room to create a more consistent procedural interface, but 
my original question still applies "consistent with what rules?"
-- 
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
Hi Lester,
The same argument applies to fresh new OO APIs. It's just a matter of
targeted PHP version to be supported. There are many things to be
considered to decide targeted PHP version other than this RFC. We have
many
new features/behaviors in newer PHP versions.I still have a major problem with the whole basis of your re-naming ...
adding the underscore at all. It was this introduction which was totally
wrong in the first place and I would rather rename the incorrectly
renamed functions if only to make them consistent with what is used in
the OO 'standard'.$main->phpVersion()
or
phpversion()Is consistent if one maintains the case insensitive rule.
Adding str_ in front of every string function where a lot are IEEE
protected is just adding confusion. Where these map to an OO API in my book
strcmp()
$str->cmp()makes sense?
Adding an extra $str_cmp is simply not necessary.Simply dropping the poorly formulated 'add underscore' rule which only
currently exists on the procedural interface and tidying up the mistake
caused by that produces a MUCH shorter list of changes and allows much
better consistency with even the existing OO interface elements?I look at the 'tidy' gd interface and simply think 'what the ****'
Yes there are some inconsistent names, but in general
imagecolorallocate
and
$image->colorAllocateis more in keeping with the other graphics libraries.
YES there is room to create a more consistent procedural interface, but
my original question still applies "consistent with what rules?"
It's possible choice. 
I agree that names without "" looks more consistent. 
Personally, I don't care much about having "" or not for procedural API. My 
only concern is naming consistency.
Names without "_" changes basic coding rule. 
Problem is how to make a choice and how to define exceptions. e.g. 
nl_langinfo()
I wonder how many of us prefer names without "_".
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
YES there is room to create a more consistent procedural interface, but
my original question still applies "consistent with what rules?"It's possible choice.
I agree that names without "" looks more consistent.
Personally, I don't care much about having "" or not for procedural API. My
only concern is naming consistency.Names without "_" changes basic coding rule.
Problem is how to make a choice and how to define exceptions. e.g.
nl_langinfo()I wonder how many of us prefer names without "_".
The one thing that your RFC demonstrates perfectly is just how much has 
to change to match that rule. Change the rule and the number of names 
that need alternatives is considerably less. I know a case was made at 
the time for adding underscores to the guidelines but it's quite clear 
that this was the mistake?
-- 
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
Lester Caine wrote on 10/03/2015 21:12:
YES there is room to create a more consistent procedural interface, but
my original question still applies "consistent with what rules?"
It's possible choice.
I agree that names without "" looks more consistent.
Personally, I don't care much about having "" or not for procedural API. My
only concern is naming consistency.Names without "_" changes basic coding rule.
Problem is how to make a choice and how to define exceptions. e.g.
nl_langinfo()I wonder how many of us prefer names without "_".
The one thing that your RFC demonstrates perfectly is just how much has
to change to match that rule. Change the rule and the number of names
that need alternatives is considerably less. I know a case was made at
the time for adding underscores to the guidelines but it's quite clear
that this was the mistake?
PHP function names are case insensitive, and conventionally written in 
lower-case (a convention that nothing decided on this list will change), 
so underscores are important for readability.
To take an example Yasuo has mentioned a couple of times, pg_lo_open() 
without any underscores at all would be pgloopen(), which is very hard 
to read: it could be pGloopen(), pgLoopEn(), pGlooPen(), pgLoOpen(), etc.
For whatever reason, PHP's users decided to go with camelCase 
identifiers for methods, rather than underscores. I don't think that was 
a decision that originated in the core distribution (which for a long 
time had very few object APIs), and I don't think it's one that can be 
changed by the core distribution (or, at this stage, anyone).
If PHP had had namespaces from day 1, and camel-case conventions, it 
would have been pg\loOpen(), but we can't change history.
Regards,
Rowan Collins 
[IMSoP]
Lester Caine wrote on 10/03/2015 21:12:
YES there is room to create a more consistent procedural interface,
but
my original question still applies "consistent with what rules?"
It's possible choice.
I agree that names without "" looks more consistent.
Personally, I don't care much about having "" or not for procedural
API. My
only concern is naming consistency.Names without "_" changes basic coding rule.
Problem is how to make a choice and how to define exceptions. e.g.
nl_langinfo()I wonder how many of us prefer names without "_".
The one thing that your RFC demonstrates perfectly is just how much has
to change to match that rule. Change the rule and the number of names
that need alternatives is considerably less. I know a case was made at
the time for adding underscores to the guidelines but it's quite clear
that this was the mistake?PHP function names are case insensitive, and conventionally written in
lower-case (a convention that nothing decided on this list will change),
so underscores are important for readability.To take an example Yasuo has mentioned a couple of times, pg_lo_open()
without any underscores at all would be pgloopen(), which is very hard
to read: it could be pGloopen(), pgLoopEn(), pGlooPen(), pgLoOpen(), etc.For whatever reason, PHP's users decided to go with camelCase
identifiers for methods, rather than underscores. I don't think that was
a decision that originated in the core distribution (which for a long
time had very few object APIs), and I don't think it's one that can be
changed by the core distribution (or, at this stage, anyone).If PHP had had namespaces from day 1, and camel-case conventions, it
would have been pg\loOpen(), but we can't change history.
But that is exactly what this RFC is trying to do?
The answer to this question is important right across the board, and the 
consistency problem only comes about because of historic decisions.
The shear volume of changes proposed in the RFC is only appropriate in 
one name space, and potentially makes what are CURRENTLY more compatible 
names with the OO style more incompatible. What is needed is a 
comprehensive solution to naming in general including all name spaces, 
and while camelCase is not documented for the core, it is USED in a lot 
of existing extensions. NEW extensions would probably follow that 
format, so why not make namespace and OO styles follow that and maintain 
the existing legacy space following the underlying IEEE standards?
-- 
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
Hi Rowan,
On Wed, Mar 11, 2015 at 9:32 PM, Rowan Collins rowan.collins@gmail.com 
wrote:
Lester Caine wrote on 10/03/2015 21:12:
YES there is room to create a more consistent procedural interface, but
my original question still applies "consistent with what rules?"
It's possible choice.
I agree that names without "" looks more consistent.
Personally, I don't care much about having "" or not for procedural
API. My
only concern is naming consistency.Names without "_" changes basic coding rule.
Problem is how to make a choice and how to define exceptions. e.g.
nl_langinfo()I wonder how many of us prefer names without "_".
The one thing that your RFC demonstrates perfectly is just how much has
to change to match that rule. Change the rule and the number of names
that need alternatives is considerably less. I know a case was made at
the time for adding underscores to the guidelines but it's quite clear
that this was the mistake?PHP function names are case insensitive, and conventionally written in
lower-case (a convention that nothing decided on this list will change), so
underscores are important for readability.To take an example Yasuo has mentioned a couple of times, pg_lo_open()
without any underscores at all would be pgloopen(), which is very hard to
read: it could be pGloopen(), pgLoopEn(), pGlooPen(), pgLoOpen(), etc.For whatever reason, PHP's users decided to go with camelCase identifiers
for methods, rather than underscores. I don't think that was a decision
that originated in the core distribution (which for a long time had very
few object APIs), and I don't think it's one that can be changed by the
core distribution (or, at this stage, anyone).If PHP had had namespaces from day 1, and camel-case conventions, it would
have been pg\loOpen(), but we can't change history.
We cannot change history, so we have to make choice that is feasible. 
I think use of "_" wasn't too bad. PHP stores function names as lower cased 
names. 
Therefore, error message says "Warning some error in 
imagecolorclosesthwb()", etc. 
It's hard to read, indeed. It also encourage users to use 
"imagecolorclosesthwb" as 
official name...
It may be better to consider how namespace for internals should be used. 
Otherwise, 
we may have to rename functions/namespaces again in the future. It may be 
for PHP8. 
It may be for PHP7.x if changes are not destructive at all.
Having namespace for internals would bring much flexibility for API 
changes, both 
OO and procedural API. I may try my best to have consensus.
I think you also like to have OO style API for basic 
variables(int/float/array) as I am. 
Unless we have good/proper procedural API names, it would be an obstacle to 
have 
OO style API for basic variables. I wish you agree to do something for it.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Having namespace for internals would bring much flexibility for API changes, both
OO and procedural API. I may try my best to have consensus.I think you also like to have OO style API for basic
variables(int/float/array) as I am.
Unless we have good/proper procedural API names, it would be an obstacle to
have OO style API for basic variables. I wish you agree to do something for it.
Personally I just want to keep the current name set and so the sheer 
volume of changes proposed is a big kick in the face to me. People are 
talking about the need for an OO based interface, but there has been no 
comment by anybody as to how that should be styled. Having switched 
everything to camelCase as part of the E_STRICT reworking that is 
already well established so while I can see why you want to complete a 
complete switch to underscore padded names THAT is not consistent with 
what everybody else is already using?
There should not be two naming styles running in parallel and that is 
all I am objecting to. If you get support for this RFC then both an 
extended namespace name set and OO based objects should all follow the 
same rules, and THAT is not what has been happening?
I think it is equally valid to ask if the current naming guide IS still 
appropriate or if a switch to camelCase for every name space is more 
practical moving forward. In which case dropping the extra underscores 
makes more sense than adding hundreds more! That a name can be written 
all lower case, all upper case or any combination is more a matter of 
choice, but as you say error messages adopt a standard that may not 
match what is in the code anyway?
-- 
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
Personally I just want to keep the current name set and so the sheer
volume of changes proposed is a big kick in the face to me.
YES!
The time to make such a change to the names is about 1998 or maybe 2000. 
Every person who learns the current names is one more reason not to 
change them now!
2015-03-12 4:08 GMT+02:00 Lester Caine lester@lsces.co.uk:
Having namespace for internals would bring much flexibility for API
changes, both
OO and procedural API. I may try my best to have consensus.I think you also like to have OO style API for basic
variables(int/float/array) as I am.
Unless we have good/proper procedural API names, it would be an obstacle
to
have OO style API for basic variables. I wish you agree to do something
for it.Personally I just want to keep the current name set and so the sheer
volume of changes proposed is a big kick in the face to me. People are
talking about the need for an OO based interface, but there has been no
comment by anybody as to how that should be styled. Having switched
everything to camelCase as part of theE_STRICTreworking that is
already well established so while I can see why you want to complete a
complete switch to underscore padded names THAT is not consistent with
what everybody else is already using?There should not be two naming styles running in parallel and that is
all I am objecting to. If you get support for this RFC then both an
extended namespace name set and OO based objects should all follow the
same rules, and THAT is not what has been happening?I think it is equally valid to ask if the current naming guide IS still
appropriate or if a switch to camelCase for every name space is more
practical moving forward. In which case dropping the extra underscores
makes more sense than adding hundreds more! That a name can be written
all lower case, all upper case or any combination is more a matter of
choice, but as you say error messages adopt a standard that may not
match what is in the code anyway?--
Lester Caine - G8HFL
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be 
frank, I do not see a new procedural api interface at all. We have one now, 
and adding a new subset of it looks pointless. It has it's problems and 
legacy, you can't really fix it. Maybe some adjustments are in order to 
make it more consistent where it can be done.
I really see only the OO API as a new additional interface. It's part 
started by the DateTime, the MySQLi classes and stuff. At this point all 
that stuff can be still namespaced, adjusted if needed and continued, just 
from the std library first. 
I, actually, use _ for function and variable naming and camelCase for 
object methods and properties.  To be frank, I like it - it visually 
clearly separates the code styles and for the most part the PHP code is 
written that way (well, the MySQLi has ->num_rows and stuff - i'd change it 
to ->numRows and so forth).
Arvids.
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new subset of it looks pointless. It has it's problems
and legacy, you can't really fix it. Maybe some adjustments are in order
to make it more consistent where it can be done.I really see only the OO API as a new additional interface. It's part
started by the DateTime, the MySQLi classes and stuff. At this point all
that stuff can be still namespaced, adjusted if needed and continued,
just from the std library first.
I, actually, use _ for function and variable naming and camelCase for
object methods and properties. To be frank, I like it - it visually
clearly separates the code styles and for the most part the PHP code is
written that way (well, the MySQLi has ->num_rows and stuff - i'd change
it to ->numRows and so forth).
This is exactly the same point I've come to ...
That MySQLi example is exactly what I am talking about. I know Postgres 
driver has been 'underscored' but it is THAT which is out of sync with 
the rest of the code base. interbase driver has the same problem, and we 
will need to bring in fbird_ to replace ibase_ there, but I use ADOdb 
almost exclusively which has been CamelCase since day one ( all be it 
with a leading capital ). PDO is camelCase but that has other problems ;)
If there has to be any tidy up, like you, I think switching back to 
loose some underscores is the less painful option.
-- 
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
2015-03-12 11:41 GMT+02:00 Lester Caine lester@lsces.co.uk:
Basically this.
Yasuo asked me some time ago how do I see the new interface, and to be
frank, I do not see a new procedural api interface at all. We have one
now, and adding a new subset of it looks pointless. It has it's problems
and legacy, you can't really fix it. Maybe some adjustments are in order
to make it more consistent where it can be done.I really see only the OO API as a new additional interface. It's part
started by the DateTime, the MySQLi classes and stuff. At this point all
that stuff can be still namespaced, adjusted if needed and continued,
just from the std library first.
I, actually, use _ for function and variable naming and camelCase for
object methods and properties. To be frank, I like it - it visually
clearly separates the code styles and for the most part the PHP code is
written that way (well, the MySQLi has ->num_rows and stuff - i'd change
it to ->numRows and so forth).This is exactly the same point I've come to ...
That MySQLi example is exactly what I am talking about. I know Postgres
driver has been 'underscored' but it is THAT which is out of sync with
the rest of the code base. interbase driver has the same problem, and we
will need to bring in fbird_ to replace ibase_ there, but I use ADOdb
almost exclusively which has been CamelCase since day one ( all be it
with a leading capital ). PDO is camelCase but that has other problems ;)If there has to be any tidy up, like you, I think switching back to
loose some underscores is the less painful option.--
Lester Caine - G8HFL
Do you mean the PostgreSQL driver needs to be changed from pg_blah() to 
pgBlah() ? 
If that's the case - why? For procedural API that's totaly fine. As I said, 
I think the functions with _ word separator are totaly fine and it's really 
no need to change that. 
The OO interface, that needs to be build eventually, that one should use 
camelCase for all the methods and properties. 
This way the code style clearly separates the OO inteface and the 
procedural interface. And I think it's good. At least it served me well all 
my 10+ years with PHP.
Arvids.
Do you mean the PostgreSQL driver needs to be changed from pg_blah() to
pgBlah() ?
It was that extra underscores having been added to the pg_ functions is 
being put forward as a reason for adding them everywhere else. That is 
perhaps when this discussion should have been undertaken, but someone 
making their prefered driver look how they want is not a good reason for 
pushing that everywhere else?
If that's the case - why? For procedural API that's totaly fine. As I
said, I think the functions with _ word separator are totaly fine and
it's really no need to change that.
Totally agree.
The OO interface, that needs to be build eventually, that one should use
camelCase for all the methods and properties.
This way the code style clearly separates the OO inteface and the
procedural interface. And I think it's good. At least it served me well
all my 10+ years with PHP.
We are on the same hymn sheet ... 
First choice ... leave things alone
Ysuo seems intent on 'consistency fixes' though so my second preference 
if it HAS to happen is simply to reduce the number of underscores
(well, the MySQLi has ->num_rows and stuff - i'd change it to ->numRows and so forth)
as an example of what works better in line with current practice elsewhere?
Current RFC is over the top.
-- 
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
2015-03-05 22:20 GMT+02:00 Yasuo Ohgaki yohgaki@ohgaki.net:
Hi Arvids,
On Thu, Mar 5, 2015 at 9:32 PM, Arvids Godjuks arvids.godjuks@gmail.com
wrote:2015-03-05 13:49 GMT+02:00 Pierre Joye pierre.php@gmail.com:
I will say it again a last time, in my opinion only a clean API;
object-like or real object as long as performance is not affected is
the only way I could see to actually solve this problem.Changing the names, argument order (pointless once we will have named
arguments, btw) and similar solutions are band aids solutions,
confusing at best, terrible at worst. It is pointless to do it after
almost two decades for some of them.--
PierreI'm with Pierre here.
Adding aliases is gonna mess up things even more. For example -
autocomplete will become hard to navigate. It's already quite lengthy list
a lot of the times and it's easier just to write the whole function name
sometimes by hand. Adding aliases will make it worse.I agree. Therefore, I'm going to update manual also so that it recommends
main function, not aliases. Aliases should be alternative.Manual and IDE don't have to list all of them. New manual lists only main
functions, does not have dedicated pages for aliases but aliases are
mentioned
in main function page as aliases.We really need a new API, that is not crossing paths with the old. That
way
people can start building stuff on new API's and we could phase out the
old
mess, for example: depricate in PHP8, remove in PHP9.
Stop-gap measures have created enough problems already, or did everyone
suddenly got an amnesia and forgot all the past lessons on the list?PHP should be multi paradigm language, not pure OO language.
IMO. Python does good job."Python is a multi-paradigm programming language: object-oriented
programming
and structured programming are fully supported, and there are a number of
language features which support functional programming and aspect-oriented
programming"
http://en.wikipedia.org/wiki/Python_%28programming_language%29It sounds like there are people who would like to discard procedural APIs.
PHP has born as procedural language. It will not happen in short term at
least. We are far from having rich and good enough OO APIs sets to make
PHP a pure OO languages.This leads to conclusion that we need to maintain/improve procedural APIs
even if we are going to make PHP a pure OO language.I finally understand why some of us against this change and suggest OO APIs
as alternative. It's reasonable making procedural APIs a
legacy/unmaintained/
messed up to discard procedural APIs someday. I'm against it. PHP should
be like Python in this regard. IMO.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Why not take advantage of namespaces and do the new API, building it up 
version by version (sure it can't be done in one go), so probably the 
extensions gonna follow too. 
That allows you to use as OO interface, so do the functions. Well, yes, it 
will be under a namespace, but at least new projects can be started that 
way. And old code will be easy enough to port, it's mostly a question of 
refactoring tools.
Aliasing is a stop-gap measure, isn't it? API's tend to get redesigned and 
PHP's is due to a major makeover. So, why not embrace it? No one's forcing 
to retire the old one any time soo, and I belive people understand it will 
be a very long time before it is phased out, if ever (well, I think in like 
20 years probably is doable). And if done right, it may be done in a way 
that if you don't need it, you can leave out the old API on compile stage - 
not sure if doable thought.
Arvids.
Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO interface, so do the functions. Well, yes,
it
will be under a namespace, but at least new projects can be started
that
way. And old code will be easy enough to port, it's mostly a question
of
refactoring tools.
Like everything else in this thread, this has been suggested before. The biggest problem is that both codebases and programmers have to work with more than one version of PHP at a time. A constantly moving target of slight variants of the same functions will be much harder to work with than a stable and well-known one which happens to have some unfortunate quirks.
Regards,
Rowan Collins 
[IMSoP]
Hi Ardids,
On Fri, Mar 6, 2015 at 8:22 AM, Arvids Godjuks arvids.godjuks@gmail.com 
wrote:
Why not take advantage of namespaces and do the new API, building it up
version by version (sure it can't be done in one go), so probably the
extensions gonna follow too.
That allows you to use as OO interface, so do the functions. Well, yes, it
will be under a namespace, but at least new projects can be started that
way. And old code will be easy enough to port, it's mostly a question of
refactoring tools.
This just does not work for people oppose to have new names for consistency. 
This proposal do not break scripts, almost. Therefore, namespace is not 
mandatory.
We should have namespace for internal functions. I agree this part. 
Even if we have namespace that could work for internal functions, we still 
need 
standard confirming names. I propose PHP and IEEE as procedural function 
name standards.
Aliasing is a stop-gap measure, isn't it? API's tend to get redesigned and
PHP's is due to a major makeover. So, why not embrace it? No one's forcing
to retire the old one any time soo, and I belive people understand it will
be a very long time before it is phased out, if ever (well, I think in like
20 years probably is doable). And if done right, it may be done in a way
that if you don't need it, you can leave out the old API on compile stage -
not sure if doable thought.
It's not about gap or having new API, but having consistent name. Most 
procedural APIs except misordered parameter do not need new API. They only 
needs consistent names.
Please suggest better/right way. Having namespace is not alternative for 
having consistent names.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Please suggest better/right way. Having namespace is not alternative for
having consistent names.
I think I did, and many other. But you seem to be convinced that 
consistency in names is the top priority and will suddenly make these 
APIs easier to use. I think we should agree to disagree and move to 
vote. I do not see any value in this discussion since quite some time, 
it is hair splitting solutions for naming, namespace, etc while not 
having an agreement on how and where to do it, except the std C names.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Hi Pierre,
Please suggest better/right way. Having namespace is not alternative for
having consistent names.I think I did, and many other. But you seem to be convinced that
consistency in names is the top priority and will suddenly make these
APIs easier to use. I think we should agree to disagree and move to
vote. I do not see any value in this discussion since quite some time,
it is hair splitting solutions for naming, namespace, etc while not
having an agreement on how and where to do it, except the std C names.
I agree namespace can be used to fix naming/parameter issues with zero BC. 
What I'm saying here is
We need new name function (and documentations/codes update) anyway
We may provide new names and new parameter order in new namespace. 
The difference is "alias" or "namespace" basically. I don't object to use 
namespace for it at all. In fact, I would love to have it even if there is 
issue 
like writing extremely difficult to read code is possible.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is "alias" or "namespace" basically. I don't object to use
namespace for it at all. In fact, I would love to have it even if there is
issue
like writing extremely difficult to read code is possible.
Hello all,
I join the thread as a seasoned PHP developer (in user-space), not as a 
PHP core developer. I work since 6 years now for large companies 
websites and I write PHP scripts and programs since 15 years now. I 
would like to bring my brick to this wall.
I follow the thread since a few days now and I have some suggestion 
which can resolve both the functions naming issue for some of you, some 
others suggested to have an object-oriented API and some are fearing 
massive BC breaks.
I read Larry Garfield and Pierre Joye suggesting the idea of an 
object-oriented API, maybe others suggested it already as long as this 
idea is running here since a few years.
I wrote these days the start of a spec of an API, it is far from being 
finished for the scalar types but the array part is almost finished and 
integrates every method documented in the current array API.
https://github.com/gplanchat/php-oop-api
Suggestions are welcome, you can fork and comment. I don't have the 
ambition to rewrite all the PHP core, but just using the existing 
underlying code and applying it a new interface in the userspace. 
Additionally to the current API.
I use the ideas from the PECL SPL types 
extension and Nikita 
Popov's scalar objects extension.
Those enhancements could be part of one RFC or several, as the amout of 
work can be massive. The essential point is that this refactoring MUST 
be using only existing code in the core. It SHOULD make it appear 
differently to the user. The risk is then lower than a full refactoring. 
It is, IMHO, the best compromise for the entire PHP community.
There are several goals and possibilities behind this :
- Create a consistent and complete API that can satisfy OOP programmers 
 and give them a more powerful API
- Do not create BC breaks on these core types, the ZVAL struct is 
 unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual
- Make it possible in a future release (let's say PHP 8, 9 or 10+) to 
 deprecate and even remove the old API
- Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE, 
 UTF-16BE, UTF-32, JIS, Big5, ect...)
Thanks for reading.
Grégory Planchat
Hi Gregory,
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is "alias" or "namespace" basically. I don't object to use
namespace for it at all. In fact, I would love to have it even if there is
issue
like writing extremely difficult to read code is possible.Hello all,
I join the thread as a seasoned PHP developer (in user-space), not as a
PHP core developer. I work since 6 years now for large companies websites
and I write PHP scripts and programs since 15 years now. I would like to
bring my brick to this wall.I follow the thread since a few days now and I have some suggestion which
can resolve both the functions naming issue for some of you, some others
suggested to have an object-oriented API and some are fearing massive BC
breaks.I read Larry Garfield and Pierre Joye suggesting the idea of an
object-oriented API, maybe others suggested it already as long as this idea
is running here since a few years.I wrote these days the start of a spec of an API, it is far from being
finished for the scalar types but the array part is almost finished and
integrates every method documented in the current array API.https://github.com/gplanchat/php-oop-api
Suggestions are welcome, you can fork and comment. I don't have the
ambition to rewrite all the PHP core, but just using the existing
underlying code and applying it a new interface in the userspace.
Additionally to the current API.I use the ideas from the [PECL SPL types extension](http://php.net/
manual/en/book.spl-types.php) and Nikita Popov's scalar objects
extension.Those enhancements could be part of one RFC or several, as the amout of
work can be massive. The essential point is that this refactoring MUST be
using only existing code in the core. It SHOULD make it appear
differently to the user. The risk is then lower than a full refactoring. It
is, IMHO, the best compromise for the entire PHP community.There are several goals and possibilities behind this :
- Create a consistent and complete API that can satisfy OOP programmers
and give them a more powerful API- Do not create BC breaks on these core types, the ZVAL struct is
unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual- Make it possible in a future release (let's say PHP 8, 9 or 10+) to
deprecate and even remove the old API- Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE,
UTF-16BE, UTF-32, JIS, Big5, ect...)Thanks for reading.
Nice post indeed! I'll insist to keep procedural API, though :) 
We are better to have unified encoding for simplicity. Multibyte string 
comparison is 
complex, so it's better to have NFC/NFG normalized UTF-8 strings as the 
default. 
Other encodings can be supported as conversions.
We are better to have consistency between procedural functions and OO 
methods 
where it is possible. I see a few inconsistencies like "hasKey", "has", 
"recursiveWalk". 
These names could be adjusted by function and/or method.
This RFC could be made so that it leaves space for consistency. i.e. Do not 
touch 
variable related functions to have consistent names for both procedural 
functions and 
OO methods in the future.
Or we may discuss/adjust consistency fully. The change may be introduced 
PHP 7.x or even PHP 8. We may take time as long as it takes and have votes 
for multiple RFCs that have consistent names/parameters at once.
The latter is better choice. IMO. 
My objective with this RFC is to make sure to have consistent procedural 
function names "someday" so that PHP will have nice and consistent 
procedural 
functions forever.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Yasuo,
Le 08/03/2015 00:44, Yasuo Ohgaki a écrit :
Hi Gregory,
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is "alias" or "namespace" basically. I don't object to use
namespace for it at all. In fact, I would love to have it even if there is
issue
like writing extremely difficult to read code is possible.Hello all,
I join the thread as a seasoned PHP developer (in user-space), not as a
PHP core developer. I work since 6 years now for large companies websites
and I write PHP scripts and programs since 15 years now. I would like to
bring my brick to this wall.I follow the thread since a few days now and I have some suggestion which
can resolve both the functions naming issue for some of you, some others
suggested to have an object-oriented API and some are fearing massive BC
breaks.I read Larry Garfield and Pierre Joye suggesting the idea of an
object-oriented API, maybe others suggested it already as long as this idea
is running here since a few years.I wrote these days the start of a spec of an API, it is far from being
finished for the scalar types but the array part is almost finished and
integrates every method documented in the current array API.https://github.com/gplanchat/php-oop-api
Suggestions are welcome, you can fork and comment. I don't have the
ambition to rewrite all the PHP core, but just using the existing
underlying code and applying it a new interface in the userspace.
Additionally to the current API.I use the ideas from the [PECL SPL types extension](http://php.net/
manual/en/book.spl-types.php) and Nikita Popov's scalar objects
extension.Those enhancements could be part of one RFC or several, as the amout of
work can be massive. The essential point is that this refactoring MUST be
using only existing code in the core. It SHOULD make it appear
differently to the user. The risk is then lower than a full refactoring. It
is, IMHO, the best compromise for the entire PHP community.There are several goals and possibilities behind this :
- Create a consistent and complete API that can satisfy OOP programmers
and give them a more powerful API- Do not create BC breaks on these core types, the ZVAL struct is
unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual- Make it possible in a future release (let's say PHP 8, 9 or 10+) to
deprecate and even remove the old API- Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE,
UTF-16BE, UTF-32, JIS, Big5, ect...)Thanks for reading.
Nice post indeed! I'll insist to keep procedural API, though :)
The point wasn't about deleting the procedural API now. I just mentioned 
it was a possibility, I meant at the (very) long term that this API 
could be deprecated or deleted, but it is not a mandatory rule.
If this appears to happen someday, it will be done after 5 or even 10 
years following PHP 7.0 release and when a very large majority of 
projects  has migrated to PHP 7 AND this possible new API. There will 
posibly be some who prefer OO and others procedural and both could 
cohabit indefinitely.
We are better to have unified encoding for simplicity. Multibyte string
comparison is
complex, so it's better to have NFC/NFG normalized UTF-8 strings as the
default.
Other encodings can be supported as conversions.
I have no personal preference for a specific default encoding as long as 
it is portable and widely used (UTF-8 seems to be the standard nowadays 
by the way).
I have though a preference for an unified API for all strings values, 
either they are managed by the standard API or mbstring or which ever 
specific extension you plan to use. This is - I think - the most 
important point, changing the default encoding could then become a 
detail (or be defined in php.ini).
Then using multiple encodings in a same script or using a same script 
for multiple encodings becomes straightforward and standard. Most PHP 
developers doesn't even know what is Unicode or a character encoding, 
they just see "odd characters that are removed with a header() call or 
utf8_decode()", no teasing intended, they just don't want to have to 
handle this. PHP should not let this sort of consideration to the sole 
awareness of user-space developers.
We are better to have consistency between procedural functions and OO
methods
where it is possible. I see a few inconsistencies like "hasKey", "has",
"recursiveWalk".
These names could be adjusted by function and/or method.
Yes, that's the point of my message, if some method names or parameter 
orders seems inconsistent to you, let's talk about it and make it more 
concistent. I also may have made mistakes or oversight witing it.
But one thing seems important to say, the docs I wrote do not map to 
existing procedural API names and parameter order, as this API is not 
concistent with itself.
To be remembered that this OO API does not use classic objects, it is 
syntaxic sugar over existing scalar, array and string types.
This RFC could be made so that it leaves space for consistency. i.e. Do not
touch
variable related functions to have consistent names for both procedural
functions and
OO methods in the future.
I don't understand what you mean with "variable related functions", are 
you talking about functions like list() and compact()?
Or we may discuss/adjust consistency fully. The change may be introduced
PHP 7.x or even PHP 8. We may take time as long as it takes and have votes
for multiple RFCs that have consistent names/parameters at once.The latter is better choice. IMO.
As some mentioned in the thread, adding aliases to the current API will 
have 2 main consequences
- create confusion for newcomers, that will not understand why there are 
 2 names for one function
- it will be difficult to impose to seasoned developers, as they shall 
 prefer to not change and keep a relatively backward-compatible code base
 instead of having to maintain 2 code bases.
Also, making all existing projects use this new API will take time, I 
remember the release of PHP 5.0 and PHP 5.1 that was at this time bothly 
not availiable on most shared hostings and not supported by most 
projects (or as a rough PHP 4 port).
Additionally, as Rasmus mentioned, lots of methods names are mappings to 
the extension's underlying C API or responding to an IEEE standard. Some 
of us are used to C development and their underlying APIs and found it 
easier to have a simple mapping between languages.
Changing evrything now would just create a Python 3 effect IMHO, even if 
I agree that it looks like confusing nowadays for newcomers, 20 years 
after the first releases of PHP. Adding an OO API is a compromise, every 
developer/team would use one or the other for his own reasons. I think 
that in a long term
My objective with this RFC is to make sure to have consistent procedural
function names "someday" so that PHP will have nice and consistent
procedural
functions forever.
I understand and, as I wrote above, this will have a big impact on the 
userbase, with consequences that are not measurable now. Maybe this 
could be done with a new language, but as PHP is now old of a couple 
decades and has multiple engines (HHVM, Phalanger, Quercus, Parrot, 
ect...), making this move is very hazardous.
I think that's the point Rasmus, Larry Garfield, Pierre Joye and others 
did have in mind, out of the pure beauty of code.
Regards,
Grégory Planchat
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character encoding,
they just see "odd characters that are removed with aheader()call or
utf8_decode()", no teasing intended, they just don't want to have to
handle this. PHP should not let this sort of consideration to the sole
awareness of user-space developers.
Not part of THIS discussion exactly, but I have to take that in 
isolation. 'Most PHP developers' need to be very aware of Unicode these 
days. Simply pretending it does not exist is a deangerous exercise and 
my own code base has been UTF8 for several years now. Even though I 
don't speak anything but English, a large section of the material one 
has to handle has characters which get lost if one does not maintain 
UTF8 through out the process. People are going on about 'data loss' when 
converting, and that applies equally to strings as numbers.
The default encoding these days is UTF8 ...
-- 
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
Le 08/03/2015 12:17, Lester Caine a écrit :
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character encoding,
they just see "odd characters that are removed with aheader()call or
utf8_decode()", no teasing intended, they just don't want to have to
handle this. PHP should not let this sort of consideration to the sole
awareness of user-space developers.Not part of THIS discussion exactly, but I have to take that in
isolation. 'Most PHP developers' need to be very aware of Unicode these
days. Simply pretending it does not exist is a deangerous exercise and
my own code base has been UTF8 for several years now. Even though I
don't speak anything but English, a large section of the material one
has to handle has characters which get lost if one does not maintain
UTF8 through out the process. People are going on about 'data loss' when
converting, and that applies equally to strings as numbers.The default encoding these days is UTF8 ...
This is not exactly what I meant, and your point is the way things 
should be, of course.
What I meant is that a text search or fetching the size of a string 
MUST behave the same way, whatever which encoding you use, without 
having to know what is the actual enconding of the string at any time.
Currently a strlen on an UTF-8 behaves more like a C "sizeof(str) - 1" 
when you are using other characters than the ASCII page.
The idea is really making these statements work, whatever the encoding 
you are using :
"Lorem ipsum dolor sit amet"->length(); 
"Lorem ipsum dolor sit amet"->search('lorem'); 
"Lorem ipsum dolor sit amet"->replace('lorem', 'Lorem');
Grégory Planchat
Then using multiple encodings in a same script or using a same script
for multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character encoding,
they just see "odd characters that are removed with aheader()call or
utf8_decode()", no teasing intended, they just don't want to have to
handle this. PHP should not let this sort of consideration to the sole
awareness of user-space developers.Not part of THIS discussion exactly, but I have to take that in
isolation. 'Most PHP developers' need to be very aware of Unicode these
days. Simply pretending it does not exist is a dangerous exercise and
my own code base has been UTF8 for several years now. Even though I
don't speak anything but English, a large section of the material one
has to handle has characters which get lost if one does not maintain
UTF8 through out the process. People are going on about 'data loss' when
converting, and that applies equally to strings as numbers.The default encoding these days is UTF8 ...
This is not exactly what I meant, and your point is the way things
should be, of course.What I meant is that a text search or fetching the size of a string
MUST behave the same way, whatever which encoding you use, without
having to know what is the actual encoding of the string at any time.Currently a strlen on an UTF-8 behaves more like a C "sizeof(str) - 1"
when you are using other characters than the ASCII page.The idea is really making these statements work, whatever the encoding
you are using :"Lorem ipsum dolor sit amet"->length();
"Lorem ipsum dolor sit amet"->search('lorem');
"Lorem ipsum dolor sit amet"->replace('lorem', 'Lorem');
This is actually the problem that trying to ignore unicode then creates 
a black hole. The amount of space needed to store the string is a 
variable once one moves outside the single byte encodings, but where 
legacy systems only allow buffering for the single byte version, one 
gets a number of problems where the data returned has multi-byte 
characters. The first example has several answers depending on what one 
is doing with the return. Size of buffer needed (sizeof in my crib 
sheet), or one of the methods of counting the number of symbols used 
(count but with an agreed decoding). The other two actually work with 
multi-byte strings until one adds 'adornments' to the characters which 
may need a search to look for a set of similar words all with the same 
meaning, just encoded differently.
My point is perhaps that it is all to easy nowadays or post/get data to 
have multi-byte strings from different languages which trying to map to 
a single byte solution is no longer appropriate. I've just been 
downloading a set of documents which are essentially all English, but 
the file names includes words from a number of other languages resulting 
in UTF8 being the only way to store them, and ideally the search engine 
should be able to find them again in the future.
-- 
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
Le 08/03/2015 16:53, Lester Caine a écrit :
"Lorem ipsum dolor sit amet"->length();
"Lorem ipsum dolor sit amet"->search('lorem');
"Lorem ipsum dolor sit amet"->replace('lorem', 'Lorem');This is actually the problem that trying to ignore unicode then creates
a black hole. The amount of space needed to store the string is a
variable once one moves outside the single byte encodings, but where
legacy systems only allow buffering for the single byte version, one
gets a number of problems where the data returned has multi-byte
characters. The first example has several answers depending on what one
is doing with the return. Size of buffer needed (sizeof in my crib
sheet), or one of the methods of counting the number of symbols used
(count but with an agreed decoding). The other two actually work with
multi-byte strings until one adds 'adornments' to the characters which
may need a search to look for a set of similar words all with the same
meaning, just encoded differently.My point is perhaps that it is all to easy nowadays or post/get data to
have multi-byte strings from different languages which trying to map to
a single byte solution is no longer appropriate. I've just been
downloading a set of documents which are essentially all English, but
the file names includes words from a number of other languages resulting
in UTF8 being the only way to store them, and ideally the search engine
should be able to find them again in the future.
I understand your point, but what I mean is not making the user totally 
unaware of the encoding, but building a common API to make it easier for 
everyone to avoid the need of permanent awareness, anywhere, anytime of 
the encoding.
Instead, make the string API make the job of choosing whichever backend 
extension is used (default or mbstring), then if the user feels the need 
of mixing encodings, he SHOULD have to be aware of it AND have the 
right transformations API availiable.
This is to make possible to simply build methods that do not need to be 
aware of encoding (eg. pure frontend text treatments) to automatically 
map to the right encoding (maybe with E_RECOVERABLE_ERROR on 
incompatible charsets).
Maybe string notations could also evolve, such as what exists in C for 
wchar_t strings (like some L prefix, or else), I have no fixed opinions 
about that and it is not the main subject anyway.
The main question is about an uniform API for strings, do you feel it is 
important/useful or not?
Grégory Planchat
Hi Gregory,
Le 08/03/2015 00:44, Yasuo Ohgaki a écrit :
Hi Gregory,
Le 07/03/2015 02:39, Yasuo Ohgaki a écrit :
We may provide new names and new parameter order in new namespace.
The difference is "alias" or "namespace" basically. I don't object to
use
namespace for it at all. In fact, I would love to have it even if there
is
issue
like writing extremely difficult to read code is possible.Hello all,
I join the thread as a seasoned PHP developer (in user-space), not as a
PHP core developer. I work since 6 years now for large companies websites
and I write PHP scripts and programs since 15 years now. I would like to
bring my brick to this wall.I follow the thread since a few days now and I have some suggestion which
can resolve both the functions naming issue for some of you, some others
suggested to have an object-oriented API and some are fearing massive BC
breaks.I read Larry Garfield and Pierre Joye suggesting the idea of an
object-oriented API, maybe others suggested it already as long as this
idea
is running here since a few years.I wrote these days the start of a spec of an API, it is far from being
finished for the scalar types but the array part is almost finished and
integrates every method documented in the current array API.https://github.com/gplanchat/php-oop-api
Suggestions are welcome, you can fork and comment. I don't have the
ambition to rewrite all the PHP core, but just using the existing
underlying code and applying it a new interface in the userspace.
Additionally to the current API.I use the ideas from the [PECL SPL types extension](http://php.net/
manual/en/book.spl-types.php) and Nikita Popov's scalar objects
extension.Those enhancements could be part of one RFC or several, as the amout of
work can be massive. The essential point is that this refactoring MUST
be
using only existing code in the core. It SHOULD make it appear
differently to the user. The risk is then lower than a full refactoring.
It
is, IMHO, the best compromise for the entire PHP community.There are several goals and possibilities behind this :
- Create a consistent and complete API that can satisfy OOP programmers
and give them a more powerful API- Do not create BC breaks on these core types, the ZVAL struct is
unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual- Make it possible in a future release (let's say PHP 8, 9 or 10+) to
deprecate and even remove the old API- Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE,
UTF-16BE, UTF-32, JIS, Big5, ect...)Thanks for reading.
Nice post indeed! I'll insist to keep procedural API, though :)
The point wasn't about deleting the procedural API now. I just mentioned
it was a possibility, I meant at the (very) long term that this API could
be deprecated or deleted, but it is not a mandatory rule.
If this appears to happen someday, it will be done after 5 or even 10
years following PHP 7.0 release and when a very large majority of projects
has migrated to PHP 7 AND this possible new API. There will posibly be
some who prefer OO and others procedural and both could cohabit
indefinitely.
Procedural API should exist forever. IMO.
We are better to have unified encoding for simplicity. Multibyte string
comparison is
complex, so it's better to have NFC/NFG normalized UTF-8 strings as the
default.
Other encodings can be supported as conversions.I have no personal preference for a specific default encoding as long as
it is portable and widely used (UTF-8 seems to be the standard nowadays by
the way).I have though a preference for an unified API for all strings values,
either they are managed by the standard API or mbstring or which ever
specific extension you plan to use. This is - I think - the most important
point, changing the default encoding could then become a detail (or be
defined in php.ini).Then using multiple encodings in a same script or using a same script for
multiple encodings becomes straightforward and standard. Most PHP
developers doesn't even know what is Unicode or a character encoding, they
just see "odd characters that are removed with aheader()call or
utf8_decode()", no teasing intended, they just don't want to have to handle
this. PHP should not let this sort of consideration to the sole awareness
of user-space developers.
I've already made UTF-8 as default PHP encoding by
https://wiki.php.net/rfc/default_encoding
Mixing encoding is nice and flexible, but it would make implementation more 
complex. It many cases needlessly. UTF-8 is standard now a days, so it 
would be the most reasonable choice for the default.
Problem is Unicode has many forms for "a character", has many ways to 
"compare" them. For example, MySQL has utf8_general_ci and utf8_unicode_ci. 
utf8_unicode_ci is just unusable with Japanese because it treats 
"パパ"(father) and "ハハ"(mother) as the same string. We may have many ways to 
compare strings, but the default should be the most reasonable one and 
string should be encoded so that simple byte by byte could be done to check 
equality if it's possible.
There are enough complex things in Unicode only, adding multiple default 
encoding support may not worth it.
We are better to have consistency between procedural functions and OO
methods
where it is possible. I see a few inconsistencies like "hasKey", "has",
"recursiveWalk".
These names could be adjusted by function and/or method.Yes, that's the point of my message, if some method names or parameter
orders seems inconsistent to you, let's talk about it and make it more
concistent. I also may have made mistakes or oversight witing it.But one thing seems important to say, the docs I wrote do not map to
existing procedural API names and parameter order, as this API is not
concistent with itself.To be remembered that this OO API does not use classic objects, it is
syntaxic sugar over existing scalar, array and string types.
I agree that these basic OO feature should be consistent with procedural 
APIs. 
I don't object to have $str->indexOf(5)/$str->length()/etc, but almost all 
of basic OO API should reflect procedural API.
This RFC could be made so that it leaves space for consistency. i.e. Do not
touch
variable related functions to have consistent names for both procedural
functions and
OO methods in the future.I don't understand what you mean with "variable related functions", are
you talking about functions like list() andcompact()?
I meant "array", "scalar" related functions.
Or we may discuss/adjust consistency fully. The change may be introduced
PHP 7.x or even PHP 8. We may take time as long as it takes and have votes
for multiple RFCs that have consistent names/parameters at once.The latter is better choice. IMO.
As some mentioned in the thread, adding aliases to the current API will
have 2 main consequences
- create confusion for newcomers, that will not understand why there are 2
names for one function- it will be difficult to impose to seasoned developers, as they shall
prefer to not change and keep a relatively backward-compatible code base
instead of having to maintain 2 code bases.
Newcomers will not be confused if they lookup new manual. There will be 
only main function listed and aliases are mentioned as "valid" function 
names unless we decide deprecate it. There is nothing wrong to use old 
names because they are valid and good names for them.
Also, making all existing projects use this new API will take time, I
remember the release of PHP 5.0 and PHP 5.1 that was at this time bothly
not availiable on most shared hostings and not supported by most projects
(or as a rough PHP 4 port).Additionally, as Rasmus mentioned, lots of methods names are mappings to
the extension's underlying C API or responding to an IEEE standard. Some of
us are used to C development and their underlying APIs and found it easier
to have a simple mapping between languages.Changing evrything now would just create a Python 3 effect IMHO, even if I
agree that it looks like confusing nowadays for newcomers, 20 years after
the first releases of PHP. Adding an OO API is a compromise, every
developer/team would use one or the other for his own reasons. I think that
in a long term
IEEE/C lib names exist as standard violating names currently. My RFC will 
make them "valid" and part of "standard". I don't think deprecating IEEE/C 
lib name functions is not good idea at all. Making them standard, or at 
least exceptions, seems only reasonable resolution for this. IMO.
My objective with this RFC is to make sure to have consistent procedural
function names "someday" so that PHP will have nice and consistent
procedural
functions forever.I understand and, as I wrote above, this will have a big impact on the
userbase, with consequences that are not measurable now. Maybe this could
be done with a new language, but as PHP is now old of a couple decades and
has multiple engines (HHVM, Phalanger, Quercus, Parrot, ect...), making
this move is very hazardous.I think that's the point Rasmus, Larry Garfield, Pierre Joye and others
did have in mind, out of the pure beauty of code.
Why hazardous? 
Old names are kept as valid function names, only new consistent names are 
introduced.
I've renamed pg_loopen() (and like) to pg_lo_open() about 10 years ago. 
http://php.net/pg_lo_open 
I didn't get even single compliant for this from users. (I'm one of a 
director of Japanese 
PostgreSQL Users Group and know many PostgreSQL and PHP users)
Programmers are used to refactoring and renaming today and old names will 
never removed 
unless there are good reasons to remove. I don't see any reasons to be 
hazardous.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Whether we like it or not, people evaluate languages by matrix like
PHP Ruby PythonOO support 5 5 5
Flexible syntax 3 5 5
AOP support 3 3 3
DbC 1 2 2
API consistency 1 3 3
API richness 4 4 4
3rd Party Libs 4 4 4
Performance 4 3 3
Security 1 4 4
Type Safety 1 4 3Although this is rough evaluation by me, people would have somewhat similar
matrix.API consistency 1 3 3
And if you add in "dozens of functions have 2 names that do the same 
thing for 'historical reasons'", that 1 is going to go down to a 0.5, 
not up.  It would be just one more thing for the Ruby biggots to poke 
fun at PHP for, not something that would quiet them down.
I know you feel strongly about this, but you're not the first. It's 
counter-productive and won't even address the marketing issue you note.
--Larry Garfield
Le 03/03/2015 00:02, Larry Garfield a écrit :
I like scalar objects, but it does not resolve that PHP has non standard
function names.
It does not change old names, therefore it's impossible to resolve
issue.
This is the reason why I'm proposing while I like scalar object, use of
namespace, etc.Again, you're contradicting yourself here - you can't say that your
mission is to change the old names, rather than offer an alternative,
but then also say that the old names will stay around forever. If both
names exist, that's exactly what you've created - an alternative.If we're going to have an alternative, let's come up with a creative
alternative that actually has an advantage to using it, not a choice
between equally cryptic names like "strripos" vs "str_ripos".Regards,
Exactly. If a PHP 7 dev has the option of:
$s = strripos($s, 'a'); // works in PHP 5+
$s = str_ripos($s, 'a'); // works in PHP 7+
Really, what's the advantage of the latter? Nothing. It's an extra
character to type, limits compatibility, and makes my life no easier.
It's useless, and will just add to the list of things people make fun of
PHP for instead of reduce it.Namespacing it is no better:
$s = str\ripos($s, 'a'); // Still useless
$s = php\str_ripos($s, 'a'); // Still uselessInstead, compare:
$s = strripos($s, 'a'); // works in PHP 5+
$s = $s->lastOccurance('a', 0, CASE_INSENSITIVE); // works in PHP 7+
Oh now we're talking! That's more self-documenting, easier to discover,
makes chaining string manipulations easier to read, solves the
needle/haystack issue, and reduces cholesterol.One is worth the effort of doing. The other is simply not.
For subsystems that aren't clear scalars, like streams, those need a
general overhaul for DX, too. Again, just doubling the number of
function names adds nothing to the language but confusion, since both
versions would have to live for at least the next decade. Offering a
substantially better alternative does improve the language. Don't waste
your time on marginal not-even-improvements.--Larry Garfield
This is, from my point of view, the direction to take. Since version 
5.0, PHP is aiming to become a true OOP language. Additionally, lots of 
projects or frameworks are using OOP style coding (and PSR standards).
What is missing today in core PHP API is scalar type hints (which I hope 
will be integrated soon in PHP7) and object scalars.
Object scalars can bring easier management for userland developers, 
without the need for them to refactor their code eg:
- mixing native numeric types with large numbers extensions (BCMath, 
 GMP, or others)
- define context-specific strings (managing ascii/utf8/utf16/type in 
 your encoding and easy cast between them, and then handling
 html/sql/console escaping with decorators, ect...). I know this is a
 sensible point due to PHP6 unicode porting failure, but making a common
 OOP API for string and mbstring extensions could be an easier way to get
 the same functionality with less painful work
As already said in this thread, Nikita Popov did an extenstion bringing 
this sort of functionalities (https://github.com/nikic/scalar_objects). 
There is also the PECL extension for Spl types 
(http://php.net/manual/en/book.spl-types.php) that could be integrated 
to the core and used as a base.
Finally, this could reopen the subject about casting magic methods : 
https://wiki.php.net/rfc/object_cast_to_types
--Grégory Planchat
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package, 
whatever. Absolutely no reason for this to be in core, and absolutely 
not worth the trouble it causes.
Sorry if this has already been said, but I'm not going to read 60 
replies, most of which are probably spam.
Leigh wrote:
Thoughts?
require 'function_aliases.php'; // End of discussion.
It is not possible to my knowledge, however, to define function aliases 
in PHP (a wrapper function would have an obvious performance penalty). 
Maybe that would be a nice addition to the language.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it causes.
I fully agree.
-- 
Christoph M. Becker
Hi Leigh,
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it causes.Sorry if this has already been said, but I'm not going to read 60
replies, most of which are probably spam.
Your reply is not a spam at all. 
I will do
require 'function_aliases.php'; // End of discussion.
If PHP has macro or userspace aliasing! 
This is one possible solution for this.
We have class_alias(). We could have function_alias().
Regards,
P.S. We still carry inconsistent names only, though. 
We may be better do this in PHP. IMHO.
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Hi Leigh,
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it causes.Sorry if this has already been said, but I'm not going to read 60
replies, most of which are probably spam.Your reply is not a spam at all.
I will dorequire 'function_aliases.php'; // End of discussion.
If PHP has macro or userspace aliasing!
This is one possible solution for this.We have
class_alias(). We could have function_alias().Regards,
P.S. We still carry inconsistent names only, though.
We may be better do this in PHP. IMHO.
Is it not time to move to the vote? I am not seeing any value continue 
this discussions. We clearly have two camps and I do not see a remote 
chance to get them agreed on something (due to the nature of this 
proposal). Let vote and move on. With the hope we will be done with 
such topic for a while.
-- 
Pierre
@pierrejoye | http://www.libgd.org
Hi Pierre,
Hi Leigh,
Thoughts?
require 'function_aliases.php'; // End of discussion.
Maintain it however you want, set it up as a composer package,
whatever. Absolutely no reason for this to be in core, and absolutely
not worth the trouble it causes.Sorry if this has already been said, but I'm not going to read 60
replies, most of which are probably spam.Your reply is not a spam at all.
I will dorequire 'function_aliases.php'; // End of discussion.
If PHP has macro or userspace aliasing!
This is one possible solution for this.We have
class_alias(). We could have function_alias().Regards,
P.S. We still carry inconsistent names only, though.
We may be better do this in PHP. IMHO.Is it not time to move to the vote? I am not seeing any value continue
this discussions. We clearly have two camps and I do not see a remote
chance to get them agreed on something (due to the nature of this
proposal). Let vote and move on. With the hope we will be done with
such topic for a while.
There are many undecided issues in the RFC. 
I'll fix these, then start voting.
Rowan suggested fixing other issues like parameter ordering. These may be 
addressed at once. If parameter ordering is fixed, new and old will be 
separate 
function. I need to research this issue. If there is good list of 
functions, I 
appreciate it.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
If PHP has macro or userspace aliasing!
This is one possible solution for this.
The engine has support for aliases. See http://php.net/manual/en/internals2.ze1.zendapi.php
If I thought this “consistency” was very important (I do not, and I fully expect an RFC on this to fail if this thread ever gets to that point), here’s what I would do:
- map out the entire inconsistency, including existing function names and parameter order, and new names + parameter orders
- write a PHP extension that does a whole bunch of ZEND_FALIAS to satisfy this new convention
- attempt to get others to use this new conventions and the extension
- once this extension has a few thousand, maybe tens of thousands of users, bring the conversation back to Internals with some actual evidence that this works and is wanted
#1 will take a long time, and it will be lots of work 
#2 is likely very easy once #1 is done (generate the aliasing code) 
#3 and #4 are questionable at best, but at least after #2, you’ll have your own unique consistency (if such a thing can exist)
Until these things happen, I can’t see this gaining any real support from any significant number of people with commit/merge access (RFC voters).
S