10 years ago by Benoit Schildknecht — view source

unread

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/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

--
Utilisant le logiciel de courrier d'Opera : http://www.opera.com/mail/

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Markus Fischer — view source

unread

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

10 years ago by S.A.N — view source

unread

Maybe better implement for method calls on primitive types in PHP 7?
https://github.com/nikic/scalar_objects

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Alain Williams — view source

unread

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)?

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

10 years ago by Yasuo Ohgaki — view source

unread

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_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.

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

10 years ago by Terry Cullen — view source

unread

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.

Also see: https://github.com/rossriley/php-scalar-objects

10 years ago by S.A.N — view source

unread

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_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.

+1

10 years ago by Yasuo Ohgaki — view source

unread

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_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.

+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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Markus Fischer — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Pierre Joye — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Stanislav Malyshev — view source

unread

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

10 years ago by Michael Schuett — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Pierre Joye — view source

unread

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/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?

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

10 years ago by Yasuo Ohgaki — view source

unread

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/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?

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

10 years ago by Pierre Joye — view source

unread

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/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?

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

10 years ago by Larry Garfield — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Larry Garfield — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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 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.

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

10 years ago by Larry Garfield — view source

unread

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

10 years ago by Markus Fischer — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rasmus Lerdorf — view source

unread

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...

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

10 years ago by Yasuo Ohgaki — view source

unread

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 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.

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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.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.

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]

10 years ago by Yasuo Ohgaki — view source

unread

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.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.

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Pierre Joye — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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.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.

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 of count())
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]

10 years ago by Yasuo Ohgaki — view source

unread

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 of count())

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.

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 return FALSE mostly.
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

10 years ago by Michael Schuett — view source

unread

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 of count())

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.

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 return FALSE mostly.

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

(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

10 years ago by Michael Schuett — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Michael Wallner — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rasmus Lerdorf — view source

unread

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

10 years ago by Trevor Suarez — view source

unread

... 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

10 years ago by guilhermeblanco@gmail.com — view source

unread

@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

10 years ago by Rasmus Lerdorf — view source

unread

@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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rasmus Lerdorf — view source

unread

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 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.

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

10 years ago by Yasuo Ohgaki — view source

unread

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:

http://pubs.opengroup.org/onlinepubs/9699919799/idx/is.html

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

10 years ago by Christian Stoller — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

Hi Christian,

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.

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

10 years ago by Christian Stoller — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

Hi Christian,

From: yohgaki@gmail.com [mailto:yohgaki@gmail.com] On Behalf Of Yasuo
Ohgaki, Sent: Thursday, March 05, 2015 9:45 AM

On 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 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.

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

10 years ago by Rasmus Lerdorf — view source

unread

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?

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

10 years ago by Yasuo Ohgaki — view source

unread

Hi Rasmus,

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?

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Lester Caine — view source

unread

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

10 years ago by christopher jones — view source

unread

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,

See #6 at https://blogs.oracle.com/opal/entry/the_mysterious_php_rfc_process

Chris

--
christopher.jones@oracle.com http://twitter.com/ghrd

10 years ago by Rowan Collins — view source

unread

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 of count())

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.

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 return FALSE mostly.

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]

10 years ago by Yasuo Ohgaki — view source

unread

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 return FALSE mostly.

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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 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?

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]

10 years ago by Yasuo Ohgaki — view source

unread

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 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?

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Pierre Joye — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Arvids Godjuks — view source

unread

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.

--
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.

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?

10 years ago by Yasuo Ohgaki — view source

unread

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.

--
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.

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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.

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 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"

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
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.

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 by define(),
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]

10 years ago by Yasuo Ohgaki — view source

unread

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 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.
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 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"
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
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.

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 by define(),
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

10 years ago by Rowan Collins — view source

unread

> Hi Rowan,
>
> On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins > > wrote:
>
> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki > > wrote:
> >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
> >
> >>> > >> wrote:
> >>>
> >>> 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
> . 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.
>

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]

10 years ago by Yasuo Ohgaki — view source

unread

On Sun, Mar 8, 2015 at 3:39 AM, Rowan Collins
wrote:

>
>
>> Hi Rowan,
>>
>> On Fri, Mar 6, 2015 at 8:50 AM, Rowan Collins >> > wrote:
>>
>> On 5 March 2015 22:05:05 GMT, Yasuo Ohgaki >> > wrote:
>> >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
>> >
>> >>> >> >> wrote:
>> >>>
>> >>> 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
>> . 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.
>>
>>
>
> 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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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 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.

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]

10 years ago by Yasuo Ohgaki — view source

unread

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 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').

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 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.

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 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.

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 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.
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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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->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?"

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Lester Caine — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Lester Caine — view source

unread

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

10 years ago by Rick Widmer — view source

unread

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!

10 years ago by Arvids Godjuks — view source

unread

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 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

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.

10 years ago by Lester Caine — view source

unread

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

10 years ago by Arvids Godjuks — view source

unread

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.

10 years ago by Lester Caine — view source

unread

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

10 years ago by Arvids Godjuks — view source

unread

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.

--
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.

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

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.

10 years ago by Rowan Collins — view source

unread

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]

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Pierre Joye — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by gregory@luni.fr — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by gregory@luni.fr — view source

unread

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

10 years ago by Lester Caine — view source

unread

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.

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

10 years ago by gregory@luni.fr — view source

unread

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 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.

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

10 years ago by Lester Caine — view source

unread

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.

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

10 years ago by gregory@luni.fr — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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 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.

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() and compact()?

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

10 years ago by Larry Garfield — view source

unread

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

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

10 years ago by gregory@luni.fr — view source

unread

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 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

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

10 years ago by Leigh — view source

unread

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.

10 years ago by Christoph Becker — view source

unread

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

10 years ago by Yasuo Ohgaki — view source

unread

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

10 years ago by Pierre Joye — view source

unread

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.

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

10 years ago by Yasuo Ohgaki — view source

unread

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 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.

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

10 years ago by Sean Coates — view source

unread

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

Consistent function names

Regards,

Regards,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Cheers,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

http://php.net/manual/en/function.ctype-alnum.php

Returns TRUE if every character in text is either a letter or a digit, FALSE otherwise.

Regards,

-- Lester Caine - G8HFL

Regards,

Regards,

https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality

https://wiki.php.net/rfc/consistent_function_names#unaffected_php_functionality

Regards,

If there are missing functions, please let me know. I'll try to address.

Regards,

Regards,

Regards,

implode() may be changed to have string implode ( string $glue , array $pieces ) always.

Regards,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Regards,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

Regards,

Cheers,

-- Lester Caine - G8HFL

-- Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

Returns `TRUE` if every character in text is either a letter or a digit,
`FALSE` otherwise.

--
Lester Caine - G8HFL

If there are missing functions, please let me know.
I'll try to address.

`implode()` may be changed to have
string implode ( string $glue , array $pieces )
always.

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL

--
Lester Caine - G8HFL