[PHP6] Function name consistency

10 years ago by Yasuo Ohgaki — view source

unread

Hi all,

I know this has been discussed before, but I'll try again.
We have following coding standard

Function names for user-level functions should be enclosed with in
the PHP_FUNCTION() macro. They should be in lowercase, with words
underscore delimited, with care taken to minimize the letter count.
Abbreviations should not be used when they greatly decrease the
readability of the function name itself::

Good:
'mcrypt_enc_self_test'
'mysql_list_fields'

Ok:
'mcrypt_module_get_algo_supported_key_sizes'
(could be 'mcrypt_mod_get_algo_sup_key_sizes'?)
'get_html_translation_table'
(could be 'html_get_trans_table'?)

Bad:
'hw_GetObjectByQueryCollObj'
'pg_setclientencoding'
'jf_n_s_i'

https://github.com/php/php-src/blob/master/CODING_STANDARDS

There are many functions that violate this for historical reason.
Since PHP has function alias feature by default, function names that
violate this standard could be renamed and keep historic names as aliases.

We may keep alias 10 or 20 years or even forever.

Good IDE can suggest correct names, but keeping inconsistent historic
function names forever damages PHP future in the long run, IMHO.

Any comments?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Hannes Magnusson — view source

unread

There are many functions that violate this for historical reason.
Since PHP has function alias feature by default, function names that
violate this standard could be renamed and keep historic names as aliases.

There was a fork at some point (few months (years?) ago) that tried
something like that.. Noone cared.

I have a local alias list='ls' cause I never remember that command to
list the contents of a directory.
I tried to fix it upstream, but ...

-Hannes

10 years ago by Ralf Lang — view source

unread

There are many functions that violate this for historical reason.
Since PHP has function alias feature by default, function names that
violate this standard could be renamed and keep historic names as aliases.

There was a fork at some point (few months (years?) ago) that tried
something like that.. Noone cared.

I have a local alias list='ls' cause I never remember that command to
list the contents of a directory.
I tried to fix it upstream, but ...

-Hannes

When redesigning for PHP6, shouldn't most functions move to a class or
namespace in the first place?

But even if you restrict it to better names, it's a step forward I
appreciate.

--
Ralf Lang
Linux Consultant / Developer
Tel.: +49-170-6381563
Mail: lang@b1-systems.de
B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

10 years ago by Rowan Collins — view source

unread

When redesigning for PHP6, shouldn't most functions move to a class or
namespace in the first place?

You make it sound like such a redesign is an obvious and achievable goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP
6 branch (Unicode strings, plus the features which were released as 5.3
and 5.4 instead) attempted anything so radical, and the more you change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I wouldn't
want to assume that whatever stopped it gaining traction in the past no
longer applies.

Regards,

--
Rowan Collins
[IMSoP]

10 years ago by Rasmus Lerdorf — view source

unread

When redesigning for PHP6, shouldn't most functions move to a class or
namespace in the first place?

You make it sound like such a redesign is an obvious and achievable goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP
6 branch (Unicode strings, plus the features which were released as 5.3
and 5.4 instead) attempted anything so radical, and the more you change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I wouldn't
want to assume that whatever stopped it gaining traction in the past no
longer applies.

You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

10 years ago by Larry Garfield — view source

unread

When redesigning for PHP6, shouldn't most functions move to a class or
namespace in the first place?
You make it sound like such a redesign is an obvious and achievable goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP
6 branch (Unicode strings, plus the features which were released as 5.3
and 5.4 instead) attempted anything so radical, and the more you change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I wouldn't
want to assume that whatever stopped it gaining traction in the past no
longer applies.
You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

Rasmus, I know you've made this point many times and it is valid
historically, but I am not convinced it's valid in the day to day
practice of most PHP developers. Only a tiny fraction of the PHP
developers I know have any knowledge of C, POSIX, etc., and I think all
of them are on this list (or were until recently). While it's great
that, for example, ext/mysql is virtually identical to The MySQL C APIs,
that is really no consolation for someone who has never looked at (nor
needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds are
it's Javascript, and after that either Python or Ruby. (I have no firm
data to back that up; it's just my gut feeling based on the developers I
interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if
nothing else; even with huge language improvements in a major version,
it still needs to be possible to run well-behaved code across several
contiguous versions or adoption will be nil. That means strlen(),
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to leave
the existing functions in place; let them be happy. Then in
PHP.nextMajor (whatever that is), add new well-developed, thought-out,
probably OOP, namespaced routines for strings, arrays/collections, etc.
Those should be based on trends, standards, and conventions that are not
older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a) {});

now that's worth doing, and worth making big changes for. But that
can/should be done without touching any of the existing functions,
because we don't want to break BC there for userspace code. If one
method happens to internally sub-call to the other in the engine, meh, I
don't care and neither does anyone else in userspace.

--Larry Garfield

10 years ago by Robert Parker — view source

unread

When redesigning for PHP6, shouldn't most functions move to a class
or
namespace in the first place?
You make it sound like such a redesign is an obvious and achievable
goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned
PHP
6 branch (Unicode strings, plus the features which were released as
5.3
and 5.4 instead) attempted anything so radical, and the more you
change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I
wouldn't
want to assume that whatever stopped it gaining traction in the past
no
longer applies.
You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command
line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I
never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

Rasmus, I know you've made this point many times and it is valid
historically, but I am not convinced it's valid in the day to day
practice of most PHP developers. Only a tiny fraction of the PHP
developers I know have any knowledge of C, POSIX, etc., and I think
all of them are on this list (or were until recently). While it's
great that, for example, ext/mysql is virtually identical to The MySQL
C APIs, that is really no consolation for someone who has never looked
at (nor needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds are
it's Javascript, and after that either Python or Ruby. (I have no
firm data to back that up; it's just my gut feeling based on the
developers I interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if
nothing else; even with huge language improvements in a major version,
it still needs to be possible to run well-behaved code across several
contiguous versions or adoption will be nil. That means strlen(),
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to
leave the existing functions in place; let them be happy. Then in
PHP.nextMajor (whatever that is), add new well-developed, thought-out,
probably OOP, namespaced routines for strings, arrays/collections,
etc. Those should be based on trends, standards, and conventions that
are not older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a)
{});

now that's worth doing, and worth making big changes for. But that
can/should be done without touching any of the existing functions,
because we don't want to break BC there for userspace code. If one
method happens to internally sub-call to the other in the engine, meh,
I don't care and neither does anyone else in userspace.

--Larry Garfield

I would consider myself one of those php developers. I know very little
c, and java. Javascript is my second language after php. Most php
developers have yet to move towards 5.3 and don't know how to even use
namespaces or what they are. They often use wordpress or drupal which
are very slow to adapt.

Considering how slow and hard it is for most php developers to migrate
to new versions of php I do not think creating aliases or changing the
names would be beneficial. Different developers would use different
aliases and it would confuse a lot of php developers.

IMO the best solution is to have more SPL objects in php 6. People can
either use the old functional php or the new OO php and the OO would
have more consistent names.

--Robert Parker

10 years ago by Tim Rhodes — view source

unread

I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer
PHP. Putting types, classes and functions behind a namespace seems the
most usable. Usually documentation is easier to understand since the
related information is always behind a namespace. Also using Pierre's
"init_set('PHP5_FUNC_COMPAT',
true);" to define the current functions (although the default should be
true) would allow older code to work without changes. Moving to namespaces
would allow better consistent naming. Although this point can be moot
because of IDEs, however it does force a developer to know what classes and
functions are going to be running in their application.

Moving strictly to an OO language would remove some of the easy for
beginners to start and easy to prototype features of the language.

Timothy Rhodes

When redesigning for PHP6, shouldn't most functions move to a class or
namespace in the first place?

You make it sound like such a redesign is an obvious and achievable goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned PHP
6 branch (Unicode strings, plus the features which were released as 5.3
and 5.4 instead) attempted anything so radical, and the more you change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I wouldn't
want to assume that whatever stopped it gaining traction in the past no
longer applies.

You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

Rasmus, I know you've made this point many times and it is valid
historically, but I am not convinced it's valid in the day to day
practice of most PHP developers. Only a tiny fraction of the PHP
developers I know have any knowledge of C, POSIX, etc., and I think
all of them are on this list (or were until recently). While it's
great that, for example, ext/mysql is virtually identical to The MySQL
C APIs, that is really no consolation for someone who has never looked
at (nor needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds are
it's Javascript, and after that either Python or Ruby. (I have no
firm data to back that up; it's just my gut feeling based on the
developers I interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if
nothing else; even with huge language improvements in a major version,
it still needs to be possible to run well-behaved code across several
contiguous versions or adoption will be nil. That means strlen(),
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to
leave the existing functions in place; let them be happy. Then in
PHP.nextMajor (whatever that is), add new well-developed, thought-out,
probably OOP, namespaced routines for strings, arrays/collections,
etc. Those should be based on trends, standards, and conventions that
are not older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a) {});

now that's worth doing, and worth making big changes for. But that
can/should be done without touching any of the existing functions,
because we don't want to break BC there for userspace code. If one
method happens to internally sub-call to the other in the engine, meh,
I don't care and neither does anyone else in userspace.

--Larry Garfield

I would consider myself one of those php developers. I know very little c,
and java. Javascript is my second language after php. Most php developers
have yet to move towards 5.3 and don't know how to even use namespaces or
what they are. They often use wordpress or drupal which are very slow to
adapt.

Considering how slow and hard it is for most php developers to migrate to
new versions of php I do not think creating aliases or changing the names
would be beneficial. Different developers would use different aliases and
it would confuse a lot of php developers.

IMO the best solution is to have more SPL objects in php 6. People can
either use the old functional php or the new OO php and the OO would have
more consistent names.

--Robert Parker

10 years ago by Robert Parker — view source

unread

I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer
PHP. Putting types, classes and functions behind a namespace seems the
most usable. Usually documentation is easier to understand since the
related information is always behind a namespace. Also using Pierre's
"init_set('PHP5_FUNC_COMPAT',
true);" to define the current functions (although the default should be
true) would allow older code to work without changes. Moving to
namespaces
would allow better consistent naming. Although this point can be moot
because of IDEs, however it does force a developer to know what classes
and
functions are going to be running in their application.

Moving strictly to an OO language would remove some of the easy for
beginners to start and easy to prototype features of the language.

Timothy Rhodes

On Thu, Jan 2, 2014 at 11:49 AM, Robert Parker rparker@yamiko.org
wrote:

When redesigning for PHP6, shouldn't most functions move to a
class or
namespace in the first place?

You make it sound like such a redesign is an obvious and achievable
goal
for the next "major" release of PHP. Neither PHP 5 nor the
abandoned PHP
6 branch (Unicode strings, plus the features which were released as
5.3
and 5.4 instead) attempted anything so radical, and the more you
change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've
only
joined the list recently. A search through the archives before
taking
this discussion further would probably avoid repeating arguments
that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I
wouldn't
want to assume that whatever stopped it gaining traction in the
past no
longer applies.

You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a
very
thin wrapper on top of dozens, now hundreds, of underlying
libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar
with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command
line
prompt.

This approach covers the majority of the functions in PHP. The
others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I
never
see the fact that most of these functions are deeply ingrained in
the
muscle memories of a lot of people addressed. And it is in our
muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

Rasmus, I know you've made this point many times and it is valid
historically, but I am not convinced it's valid in the day to day
practice of most PHP developers. Only a tiny fraction of the PHP
developers I know have any knowledge of C, POSIX, etc., and I think
all of them are on this list (or were until recently). While it's
great that, for example, ext/mysql is virtually identical to The
MySQL
C APIs, that is really no consolation for someone who has never
looked
at (nor needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds
are
it's Javascript, and after that either Python or Ruby. (I have no
firm data to back that up; it's just my gut feeling based on the
developers I interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if
nothing else; even with huge language improvements in a major
version,
it still needs to be possible to run well-behaved code across several
contiguous versions or adoption will be nil. That means strlen(),
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to
leave the existing functions in place; let them be happy. Then in
PHP.nextMajor (whatever that is), add new well-developed,
thought-out,
probably OOP, namespaced routines for strings, arrays/collections,
etc. Those should be based on trends, standards, and conventions
that
are not older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a)
{});

now that's worth doing, and worth making big changes for. But that
can/should be done without touching any of the existing functions,
because we don't want to break BC there for userspace code. If one
method happens to internally sub-call to the other in the engine,
meh,
I don't care and neither does anyone else in userspace.

--Larry Garfield

I would consider myself one of those php developers. I know very
little c,
and java. Javascript is my second language after php. Most php
developers
have yet to move towards 5.3 and don't know how to even use namespaces
or
what they are. They often use wordpress or drupal which are very slow
to
adapt.

Considering how slow and hard it is for most php developers to migrate
to
new versions of php I do not think creating aliases or changing the
names
would be beneficial. Different developers would use different aliases
and
it would confuse a lot of php developers.

IMO the best solution is to have more SPL objects in php 6. People can
either use the old functional php or the new OO php and the OO would
have
more consistent names.

--Robert Parker

--

I was not implying an OO only language. I love how php is not strictly
OO. The point I was trying to get across is that most php developers
will not adapt until unless they absolutely have too. Changing functions
would be a huge deal to these people. using a tool is probably out of
the question for them unless it was a gui based tool. Allowing different
names would be confusing to them also. IDEs wouln't help IMO because
they don't use them.

I have been using PHP for about 5 years and just started my career as a
web developer. TBH I have only once meet someone who uses version
control and knows what namespaces are. only a few people used an IDE or
knew what an IDE was. I know there's a lot of great php developers out
there but I do not think the make up the majority. Maybe it's
demographics. I live in OR USA.

I think we should leave the functions as they are and include more SPL
objects. The SPL would be more consistent for the people who do OOP.

10 years ago by Florin Patan — view source

unread

I've done PHP, C, Javascript, and C# for 15 years now. I greatly prefer
PHP. Putting types, classes and functions behind a namespace seems the
most usable. Usually documentation is easier to understand since the
related information is always behind a namespace. Also using Pierre's
"init_set('PHP5_FUNC_COMPAT',
true);" to define the current functions (although the default should be
true) would allow older code to work without changes. Moving to namespaces
would allow better consistent naming. Although this point can be moot
because of IDEs, however it does force a developer to know what classes
and
functions are going to be running in their application.

Moving strictly to an OO language would remove some of the easy for
beginners to start and easy to prototype features of the language.

Timothy Rhodes

When redesigning for PHP6, shouldn't most functions move to a class
or
namespace in the first place?

You make it sound like such a redesign is an obvious and achievable
goal
for the next "major" release of PHP. Neither PHP 5 nor the abandoned
PHP
6 branch (Unicode strings, plus the features which were released as
5.3
and 5.4 instead) attempted anything so radical, and the more you
change,
the harder it is to persuade people to migrate.

I suspect this has been discussed a lot of times, although I've only
joined the list recently. A search through the archives before taking
this discussion further would probably avoid repeating arguments that
have been had before, unless anyone has a good summary somewhere?

Not that I'm against moving towards consistency per se, but I wouldn't
want to assume that whatever stopped it gaining traction in the past
no
longer applies.

You also need to realize that there is consistency. It is just
consistency from a different angle. PHP from day one was always a very
thin wrapper on top of dozens, now hundreds, of underlying libraries.
The function names and argument order, for the most part, were taken
directly from these underlying libraries. So if you were familiar with
MySQL's C API, for example, you would instantly be able to navigate
PHP's mysql functions to the point where we barely needed PHP MySQL
documentation because MySQL's C library documentation covered it
function for function. And for many of the str functions (the ones
without an underscore), try typing: man
strlen/strchr/strrchr/strtok/strpbr/strspn... at your Linux command
line
prompt.

This approach covers the majority of the functions in PHP. The others
are somewhat haphazard because it was not always obvious how to name
these given there was no underlying API to mimic.

So, whenever I see these, "let's just rename everything" posts, I never
see the fact that most of these functions are deeply ingrained in the
muscle memories of a lot of people addressed. And it is in our muscle
memories, not because of PHP, but because we still live in a world
written in C. As soon as you venture outside the world of PHP and
scripting languages, you hit this world.

That doesn't mean we can't try to address this, but simply renaming
everything is not the answer.

-Rasmus

Rasmus, I know you've made this point many times and it is valid
historically, but I am not convinced it's valid in the day to day
practice of most PHP developers. Only a tiny fraction of the PHP
developers I know have any knowledge of C, POSIX, etc., and I think
all of them are on this list (or were until recently). While it's
great that, for example, ext/mysql is virtually identical to The MySQL
C APIs, that is really no consolation for someone who has never looked
at (nor needed to, nor had any desire to) the MySQL C bindings.

I'm pretty sure most PHP developers' second language isn't C; odds are
it's Javascript, and after that either Python or Ruby. (I have no
firm data to back that up; it's just my gut feeling based on the
developers I interact with across the community.)

I agree that "rename all the things" doesn't help, for BC reasons if
nothing else; even with huge language improvements in a major version,
it still needs to be possible to run well-behaved code across several
contiguous versions or adoption will be nil. That means strlen(),
strrchr(), etc. are not going anywhere.

What I'd suggest instead, and I am not the first to suggest, is to
leave the existing functions in place; let them be happy. Then in
PHP.nextMajor (whatever that is), add new well-developed, thought-out,
probably OOP, namespaced routines for strings, arrays/collections,
etc. Those should be based on trends, standards, and conventions that
are not older than half the people on this list.

Replacing \strlen() with \string_length() has no real value, I agree.
However, (as an example) offering

$string->length()
"some string"->length()
$iterable_including_arrays->map(function($a){})->filter(function($a)
{});

now that's worth doing, and worth making big changes for. But that
can/should be done without touching any of the existing functions,
because we don't want to break BC there for userspace code. If one
method happens to internally sub-call to the other in the engine, meh,
I don't care and neither does anyone else in userspace.

--Larry Garfield

I would consider myself one of those php developers. I know very little
c,
and java. Javascript is my second language after php. Most php developers
have yet to move towards 5.3 and don't know how to even use namespaces or
what they are. They often use wordpress or drupal which are very slow to
adapt.

Considering how slow and hard it is for most php developers to migrate to
new versions of php I do not think creating aliases or changing the names
would be beneficial. Different developers would use different aliases and
it would confuse a lot of php developers.

IMO the best solution is to have more SPL objects in php 6. People can
either use the old functional php or the new OO php and the OO would have
more consistent names.

--Robert Parker

--

I was not implying an OO only language. I love how php is not strictly OO.
The point I was trying to get across is that most php developers will not
adapt until unless they absolutely have too. Changing functions would be a
huge deal to these people. using a tool is probably out of the question for
them unless it was a gui based tool. Allowing different names would be
confusing to them also. IDEs wouln't help IMO because they don't use them.

I have been using PHP for about 5 years and just started my career as a web
developer. TBH I have only once meet someone who uses version control and
knows what namespaces are. only a few people used an IDE or knew what an IDE
was. I know there's a lot of great php developers out there but I do not
think the make up the majority. Maybe it's demographics. I live in OR USA.

I think we should leave the functions as they are and include more SPL
objects. The SPL would be more consistent for the people who do OOP.

--

(This not PHP specific nor it's targeted any specific person or group)

So, the argument of having a bad language is that if the people who
use it are bad then it should stay bad forever? Shouldn't a language
strive to be better and better, promote good practices and enhance the
way people program not just write code?

And if it's that hard to run "php -5to6 /path/to/file.php" then I
guess one needs to wonder if he's really in the right business. Yes,
you may have a tool that is using some fancy interface, but CLI itself
is also a GUI on it's own.

Maybe making the whole thing consistent is coming a bit too late now
in the game, at least for old stuff and considering the spread of PHP
there's going to be lots of people frustrated about changes. Something
like this shouldn't be treated lightly nor should it be done without a
form of automated migration (again, engine support is not that
solution). But on the other hand, sticking to a solution because it's
yours or because you got accustomed to it it's not something a
programmer should do either.

As for PHP6 to come to life and be adopted, besides a single 'oh look,
PHP6 is here with all the functions renamed / parameter shifted
around' it has to come with more then that, HHVM integration is a good
start, seeing how it's holding pretty well in benchmarks and finally
it's being considered as something that might be looked into in the
future, something that a year ago was a: 'oh no, no'.

Regards,
Florin

Florin Patan / @dlsniper
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

10 years ago by Rasmus Lerdorf — view source

unread

As for PHP6 to come to life and be adopted, besides a single 'oh look,
PHP6 is here with all the functions renamed / parameter shifted
around' it has to come with more then that, HHVM integration is a good
start, seeing how it's holding pretty well in benchmarks and finally
it's being considered as something that might be looked into in the
future, something that a year ago was a: 'oh no, no'.

Because it was a completely different thing then which FB also realized
and completely changed gears to be more in line with PHP. Now that they
have done that it is much more interesting to us. If they hadn't, it
would still be an 'oh no, no' as you so eloquently and mockingly put it.

-Rasmus

10 years ago by Yasuo Ohgaki — view source

unread

HI all,

I would consider myself one of those php developers. I know very little c,
and java. Javascript is my second language after php. Most php developers
have yet to move towards 5.3 and don't know how to even use namespaces or
what they are. They often use wordpress or drupal which are very slow to
adapt.

Considering how slow and hard it is for most php developers to migrate to
new versions of php I do not think creating aliases or changing the names
would be beneficial. Different developers would use different aliases and
it would confuse a lot of php developers.

This proposal does not intend to force users to adopt new names, but ensure
PHP popularity in the long run.

Are new users willing to learn language that have full of inconsistent
names
even for basic/standard/default functions?

My intention to have consistent function names for old function is

to ensure PHP as attractive language to learn even 10 or 20 years later.

I agree that adoption of new feature is slow. If we made function names
consistent now, there would be codes around uses historic names 10 years
later, but it does not matter for the purpose of this proposal.

De facto Standard names such as strchr() would be acceptable names even
20 years from now. Other functions such as GD functions are better to have
consistent names.

Please consider this proposal is for new users that will learn PHP from now
or
in the future.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Florin Patan — view source

unread

HI all,

I would consider myself one of those php developers. I know very little c,
and java. Javascript is my second language after php. Most php developers
have yet to move towards 5.3 and don't know how to even use namespaces or
what they are. They often use wordpress or drupal which are very slow to
adapt.

Considering how slow and hard it is for most php developers to migrate to
new versions of php I do not think creating aliases or changing the names
would be beneficial. Different developers would use different aliases and
it would confuse a lot of php developers.

This proposal does not intend to force users to adopt new names, but ensure
PHP popularity in the long run.

Are new users willing to learn language that have full of inconsistent
names
even for basic/standard/default functions?

My intention to have consistent function names for old function is

to ensure PHP as attractive language to learn even 10 or 20 years later.

I agree that adoption of new feature is slow. If we made function names
consistent now, there would be codes around uses historic names 10 years
later, but it does not matter for the purpose of this proposal.

De facto Standard names such as strchr() would be acceptable names even
20 years from now. Other functions such as GD functions are better to have
consistent names.

Please consider this proposal is for new users that will learn PHP from now
or
in the future.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

If you look at golang you'll see they have 'go fix'
http://golang.org/cmd/fix/ which helps mitigate the effects of
language changes automatically.

I suppose it wouldn't be a problem with having a tool that can
generate an AST out of a .php file and dump it back to a newer syntax
(as long as only the function / method / classes name and parameter
order is changing).

The issue I see is that people are stuck into the: 'bbbut it's using
the underlying uber-duper library and if a dozen people know about it
then it must be a good thing' approach.

Also, having a flag in the engine, with some ini_set(blah, true) seems
like a poor decision imo. Fix the problem at the source, don't clutter
the engine because the php users are too lazy to run an automated
tool.

And yes, I do suggest that PHP should start to impose a certain
formatting, since it would be needed by this tool, but if you look
past the initial: ':(((( I want my tabs / spaces back' or whatever, in
a couple of days / weeks everyone would forget about the formatting
issues and just focus on the code.

@Yasuo, if you really want to keep PHP attractive maybe you should
look on what golang is doing because imo they served every other
languages a lesson in tooling and not only.

Florin Patan / @dlsniper
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

10 years ago by Yasuo Ohgaki — view source

unread

Hi Florin,

@Yasuo, if you really want to keep PHP attractive maybe you should
look on what golang is doing because imo they served every other
languages a lesson in tooling and not only.

Thanks.
I'm not familiar with Go yet, but I have an idea for DbC (design by
contract) for PHP.
Anyway, I'll learn it soon :)

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Florin Patan — view source

unread

Hi Florin,

@Yasuo, if you really want to keep PHP attractive maybe you should
look on what golang is doing because imo they served every other
languages a lesson in tooling and not only.

Thanks.
I'm not familiar with Go yet, but I have an idea for DbC (design by
contract) for PHP.
Anyway, I'll learn it soon :)

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Also Pythons' 2to3 might be interesting to check out:
http://docs.python.org/2/library/2to3.html
Cheers.

Florin Patan / @dlsniper
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan

10 years ago by Rowan Collins — view source

unread

I suppose it wouldn't be a problem with having a tool that can
generate an AST out of a .php file and dump it back to a newer syntax
(as long as only the function / method / classes name and parameter
order is changing).

Don't forget that there are various ways to do what could loosely be
described as "reflection" or "meta-programming" in PHP - e.g. given
call_user_func_array($func, $args) we may need to correct the name
stored in the string $func, or the order of items in the array $args.

These are very hard to even detect with an automated tool, let alone fix

indeed, I doubt it is even theoretically possible in many cases. That
leaves you with either code that needs painstaking manual upgrades, or a
runtime compatibility mode.

Both of these come with a cost to the community at large - many people
want to distribute (or internally manage) code that is both backwards
and forwards compatible, i.e. runs on as many past and future versions
of the platform as possible. That's impossible to do with a hard
compatibility break, and tricky if the compatibility breaks are subtle
(such as new function names/aliases) as you have to keep testing and
removing the new names until you no longer need to support the old versions.

A more fundamental restructuring (e.g. an OO implementation of "basic"
operations) could more happily sit alongside the existing functionality,
with code very obviously using either one style or the other, and
compatibility easy to maintain over the longer term.

Regards,

--
Rowan Collins
[IMSoP]

10 years ago by Pierre Joye — view source

unread

Hi all,

I know this has been discussed before, but I'll try again.
We have following coding standard

Function names for user-level functions should be enclosed with in
the PHP_FUNCTION() macro. They should be in lowercase, with words
underscore delimited, with care taken to minimize the letter count.
Abbreviations should not be used when they greatly decrease the
readability of the function name itself::

There are a couple of solutions to this problem.

Change all the existing functions signatures. Bad idea per se as we can
forget any fast adoption, if any at all. Will be very painful to migrate
existing code
Add aliases all around.
Not a big fan of that one either. It clutters the php NS a lot without
factual gains
Try to implement nickic's prototype to add methods to scalar related
types, should work with complex types as well

I would prefer to give 3. a try, while it could be tricky to implement a
technically acceptable solution.

Pros:

. It will bring consistent APIs
. does not add dozen of aliases for little gains
. fully BC
. fits more to current development habits

Cons:
. still have to be careful by designing the new "methods"

Cheers,
Pierre

10 years ago by Nils Andre — view source

unread

Hi Folks,

I really like the idea from Larry Garfield or Pierre Joye's proposal (3).

We now do have some things cluttered, and it does not matter because
of what this is cluttered or if it's only the C world shining through.
Programmatically spoken, to me and many OO folks, these things are
inconsitently named and the strlen("somesting")... syntax is very
1980s to have.

Anyways, any change should not break existing code, but must strive
for new code being written to be more maintainable, readable and
OOP-like.

Either these functions must live in this space forever (and can get
proper aliases or mappings to OO-compliant syntax), or, if one tends
to disable them, we could have some switch in INI or in a script,
enabling all of them back again, like

init_set('PHP5_FUNC_COMPAT', true);

For old projects that depend on them, the main PHP include would then
include this flag and the functions would be made available.

Cheers,
Nils

2014/1/2 Pierre Joye pierre.php@gmail.com:

Hi all,

I know this has been discussed before, but I'll try again.
We have following coding standard

Function names for user-level functions should be enclosed with in
the PHP_FUNCTION() macro. They should be in lowercase, with words
underscore delimited, with care taken to minimize the letter count.
Abbreviations should not be used when they greatly decrease the
readability of the function name itself::

There are a couple of solutions to this problem.

Change all the existing functions signatures. Bad idea per se as we can
forget any fast adoption, if any at all. Will be very painful to migrate
existing code

Add aliases all around.
Not a big fan of that one either. It clutters the php NS a lot without
factual gains

Try to implement nickic's prototype to add methods to scalar related
types, should work with complex types as well

I would prefer to give 3. a try, while it could be tricky to implement a
technically acceptable solution.

Pros:

. It will bring consistent APIs
. does not add dozen of aliases for little gains
. fully BC
. fits more to current development habits

Cons:
. still have to be careful by designing the new "methods"

Cheers,
Pierre

10 years ago by Yasuo Ohgaki — view source

unread

I know this has been discussed before, but I'll try again.
We have following coding standard

Function names for user-level functions should be enclosed with in
the PHP_FUNCTION() macro. They should be in lowercase, with words
underscore delimited, with care taken to minimize the letter count.
Abbreviations should not be used when they greatly decrease the
readability of the function name itself::

Good:
'mcrypt_enc_self_test'
'mysql_list_fields'

Ok:
'mcrypt_module_get_algo_supported_key_sizes'
(could be 'mcrypt_mod_get_algo_sup_key_sizes'?)
'get_html_translation_table'
(could be 'html_get_trans_table'?)

Bad:
'hw_GetObjectByQueryCollObj'
'pg_setclientencoding'
'jf_n_s_i'

https://github.com/php/php-src/blob/master/CODING_STANDARDS

There are many functions that violate this for historical reason.
Since PHP has function alias feature by default, function names that
violate this standard could be renamed and keep historic names as aliases.

We may keep alias 10 or 20 years or even forever.

Good IDE can suggest correct names, but keeping inconsistent historic
function names forever damages PHP future in the long run, IMHO.

Any comments?

Added RFC for this.

https://wiki.php.net/rfc/consistent-names

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Andrea Faulds — view source

unread

Added RFC for this.

https://wiki.php.net/rfc/consistent-names

You seem pretty eager to make RFCs ;)

You should probably announce it to the list directly as well.

--
Andrea Faulds
http://ajf.me/

10 years ago by Yasuo Ohgaki — view source

unread

Hi Andrea,

Added RFC for this.

https://wiki.php.net/rfc/consistent-names

You seem pretty eager to make RFCs ;)

You should probably announce it to the list directly as well.

I just don't want to forget about it :)
I made it as reminder. Since we are 5.6 release phase, it might
be better bring up this after 5.6 release.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Chris Wright — view source

unread

Maybe it's a stupid idea, you'll tell me :) Wouldn't it be a good thing to
issue a notice when people use the alias instead of the correct function
name?

This is essentially a description of the visible effects of
deprecation, and would cause a lot of issues in userland if this was
done straight away, since there are literally millions of applications
using functions that are candidates to be aliased in every page load -
remember that everything, including error messages, has an overhead.

As Yasuo stated in the first message in the thread:

We may keep alias 10 or 20 years or even forever.

We can't consider deprecating (or even "soft deprecating" in the
manual, as happened with ext/mysql) any of the old names for a long,
long time, as many of them are far to deeply burned into the PHP
ecosystem.

Thanks, Chris

10 years ago by Larry Garfield — view source

unread

Therein lies the whole problem with adding more aliases - it just makes
things more inconsistent, as developers can use (deliberately or
accidentally) different names for the same function.

I still have to think a moment when I see sizeof() or print, rather than
count() or echo - let alone having to remember which version of PHP
introduced which alias so that libraries don't break when deployed to
older servers.

I think it's far better to have replacements for whole sets of functions
that are clearly "new and shiny" - be that OO strings and arrays, or
just namespaces for extensions like mbstring. In fact, a namespace for
mbstring could allow a much cleaner version of the "override normal
string functions" system, because you could just "use" the namespace,
and have functions with overlapping names...

Regards,
Rowan Collins
[IMSoP]

Agreed. Simply aliasing a bunch of functions offers no useful value,
but does increase confusion. ("Wait, do I use strcmp() or
string_compare() on this project? What version are we on again? Oh,
look, this library uses both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

--Larry Garfield

10 years ago by Yasuo Ohgaki — view source

unread

Hi Larry,

On Fri, Jan 24, 2014 at 10:11 AM, Larry Garfield larry@garfieldtech.comwrote:

Therein lies the whole problem with adding more aliases - it just makes

things more inconsistent, as developers can use (deliberately or
accidentally) different names for the same function.

I still have to think a moment when I see sizeof() or print, rather than
count() or echo - let alone having to remember which version of PHP
introduced which alias so that libraries don't break when deployed to
older servers.

I think it's far better to have replacements for whole sets of functions
that are clearly "new and shiny" - be that OO strings and arrays, or
just namespaces for extensions like mbstring. In fact, a namespace for
mbstring could allow a much cleaner version of the "override normal
string functions" system, because you could just "use" the namespace,
and have functions with overlapping names...

Regards,
Rowan Collins
[IMSoP]

Agreed. Simply aliasing a bunch of functions offers no useful value, but
does increase confusion. ("Wait, do I use strcmp() or string_compare() on
this project? What version are we on again? Oh, look, this library uses
both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

We should be careful choosing names. I agree.
However, not adding more function names is simply impossible.
For example, I'm about to add new session function named

string session_create_id([string $prefix])

for user save handlers, so that user could generate secure ID
easily. It's a straight name for session ID creation and there
might be users using this name.

Not adding any new names means not adding any new features
nor cleanups.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Larry Garfield — view source

unread

Agreed. Simply aliasing a bunch of functions offers no useful value, but
does increase confusion. ("Wait, do I use strcmp() or string_compare() on
this project? What version are we on again? Oh, look, this library uses
both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

We should be careful choosing names. I agree.
However, not adding more function names is simply impossible.
For example, I'm about to add new session function named

string session_create_id([string $prefix])

for user save handlers, so that user could generate secure ID
easily. It's a straight name for session ID creation and there
might be users using this name.

Not adding any new names means not adding any new features
nor cleanups.

Regards,

I don't mean "never add a function again". I mean adding functions for
no particular value other than having more of them helps nothing, and
arguably makes the situation worse. Where possible, we shouldn't be
adding yet-another-utility-function but looking to how to build more
complete and functional language capabilities and standard libraries,
rather than piecemeal addition of functions one RFC at a time.

For your example, for instance, session handling is as of PHP 5.4 an
object. That's the cleaner way to handle it than a bunch of functions.
Can that function be better integrated into an API rather than just
added to a long list of tools? I don't know; maybe. But we should be
asking those questions, not saying "how many more ways to type strcmp()
can we introduce to confuse people."

--Larry Garfield

10 years ago by Yasuo Ohgaki — view source

unread

Hi Larry,

On Sat, Jan 25, 2014 at 5:38 AM, Larry Garfield larry@garfieldtech.comwrote:

Agreed. Simply aliasing a bunch of functions offers no useful value, but

does increase confusion. ("Wait, do I use strcmp() or string_compare()
on
this project? What version are we on again? Oh, look, this library uses
both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

We should be careful choosing names. I agree.
However, not adding more function names is simply impossible.
For example, I'm about to add new session function named

string session_create_id([string $prefix])

for user save handlers, so that user could generate secure ID
easily. It's a straight name for session ID creation and there
might be users using this name.

Not adding any new names means not adding any new features
nor cleanups.

Regards,

I don't mean "never add a function again". I mean adding functions for no
particular value other than having more of them helps nothing, and arguably
makes the situation worse. Where possible, we shouldn't be adding
yet-another-utility-function but looking to how to build more complete and
functional language capabilities and standard libraries, rather than
piecemeal addition of functions one RFC at a time.

For your example, for instance, session handling is as of PHP 5.4 an
object. That's the cleaner way to handle it than a bunch of functions.
Can that function be better integrated into an API rather than just added
to a long list of tools? I don't know; maybe. But we should be asking
those questions, not saying "how many more ways to type strcmp() can we
introduce to confuse people."

I think we have different objective.

Better PHP for future users.
vs
Better PHP for current users.

Both objectives are important, IMHO.
My intention is to make/keep PHP attractive language to learn.

We have namespace, so name collision is not much issue
now a days, isn't it? I know there are many apps w/o namespace,
though. There is a way to work round at least.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Rowan Collins — view source

unread

Hi Larry,

On Fri, Jan 24, 2014 at 10:11 AM, Larry Garfield larry@garfieldtech.comwrote:

Therein lies the whole problem with adding more aliases - it just makes

things more inconsistent, as developers can use (deliberately or
accidentally) different names for the same function.
Agreed. Simply aliasing a bunch of functions offers no useful value, but
does increase confusion. ("Wait, do I use strcmp() or string_compare() on
this project? What version are we on again? Oh, look, this library uses
both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

We should be careful choosing names. I agree.
However, not adding more function names is simply impossible.

The discussion seems to have veered off on a tangent here - we were
talking about adding aliases (new names for existing functions) that
were more consistent/standardised, and why that can cause more harm than
good.

Adding new functions for new functionality is an entirely different
discussion. In general, I do feel that piecemeal additions like
array_column() have a rather marginal benefit, and it would be nice if
more parts of the standard library used OOP or at least namespaces, but
having a rich standard library of functions is definitely a good thing.
The password_* functions, for instance, are an excellent thing to have
standardised and ready "out of the box".

But that's all completely beside the point in a discussion about giving
existing functions new names.

Regards,

--
Rowan Collins
[IMSoP]

10 years ago by Yasuo Ohgaki — view source

unread

Hi Rowan,

On Sun, Jan 26, 2014 at 4:24 AM, Rowan Collins rowan.collins@gmail.comwrote:

Hi Larry,

On Fri, Jan 24, 2014 at 10:11 AM, Larry Garfield <larry@garfieldtech.com

wrote:

Therein lies the whole problem with adding more aliases - it just makes

things more inconsistent, as developers can use (deliberately or
accidentally) different names for the same function.

Agreed. Simply aliasing a bunch of functions offers no useful value, but

does increase confusion. ("Wait, do I use strcmp() or string_compare()
on
this project? What version are we on again? Oh, look, this library uses
both. Must have been different devs. FML.")

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about. Don't add more.

We should be careful choosing names. I agree.
However, not adding more function names is simply impossible.

The discussion seems to have veered off on a tangent here - we were
talking about adding aliases (new names for existing functions) that were
more consistent/standardised, and why that can cause more harm than good.

For example, I've made pg_query() long time ago while there was pg_exec().
http://jp2.php.net/manual/en/function.pg-query.php

At that time, there wasn't a prepared query. Now we have pg_execute() to
execute
prepared query.

I guess not many people consider this was harmful.

Adding new functions for new functionality is an entirely different

discussion. In general, I do feel that piecemeal additions like
array_column() have a rather marginal benefit, and it would be nice if more
parts of the standard library used OOP or at least namespaces, but having a
rich standard library of functions is definitely a good thing. The
password_* functions, for instance, are an excellent thing to have
standardised and ready "out of the box".

But that's all completely beside the point in a discussion about giving
existing functions new names.

My question is, are people willing to learn/keep using PHP 10 years later?
People don't choose languages by function names, but how they feel
would be important.

We might had pg_exec() and pg_execute() while most other database module
uses *_query() for executing SQL text directly. We may say it's been named
after PQexec, so there is pg_exec(), no pg_query() forever. It's
acceptable, but
it's not optimum.

Adding aliases for cleanup does not worth the effort now. I agree.
However, it does for future. IMHO.

Name collision by adding aliases is not much issue with namespace.
Anyone who don't care cleanup, they don't have to care and keep
using old names.

For example, pgsql module has many aliases. These are about 10 years old or
so
and these aliases will be in the module many more years.

/* aliases for downwards compatibility */
PHP_FALIAS(pg_exec,          pg_query,          arginfo_pg_query)
PHP_FALIAS(pg_getlastoid,    pg_last_oid,       arginfo_pg_last_oid)

#if HAVE_PQCMDTUPLES
PHP_FALIAS(pg_cmdtuples, pg_affected_rows,
arginfo_pg_affected_rows)
#endif
PHP_FALIAS(pg_errormessage, pg_last_error, arginfo_pg_last_error)
PHP_FALIAS(pg_numrows, pg_num_rows, arginfo_pg_num_rows)
PHP_FALIAS(pg_numfields, pg_num_fields, arginfo_pg_num_fields)
PHP_FALIAS(pg_fieldname, pg_field_name, arginfo_pg_field_name)
PHP_FALIAS(pg_fieldsize, pg_field_size, arginfo_pg_field_size)
PHP_FALIAS(pg_fieldtype, pg_field_type, arginfo_pg_field_type)
PHP_FALIAS(pg_fieldnum, pg_field_num, arginfo_pg_field_num)
PHP_FALIAS(pg_fieldprtlen, pg_field_prtlen, arginfo_pg_field_prtlen)
PHP_FALIAS(pg_fieldisnull, pg_field_is_null,
arginfo_pg_field_is_null)
PHP_FALIAS(pg_freeresult, pg_free_result, arginfo_pg_free_result)
PHP_FALIAS(pg_result, pg_fetch_result, arginfo_pg_get_result)
PHP_FALIAS(pg_loreadall, pg_lo_read_all, arginfo_pg_lo_read_all)
PHP_FALIAS(pg_locreate, pg_lo_create, arginfo_pg_lo_create)
PHP_FALIAS(pg_lounlink, pg_lo_unlink, arginfo_pg_lo_unlink)
PHP_FALIAS(pg_loopen, pg_lo_open, arginfo_pg_lo_open)
PHP_FALIAS(pg_loclose, pg_lo_close, arginfo_pg_lo_close)
PHP_FALIAS(pg_loread, pg_lo_read, arginfo_pg_lo_read)
PHP_FALIAS(pg_lowrite, pg_lo_write, arginfo_pg_lo_write)
PHP_FALIAS(pg_loimport, pg_lo_import, arginfo_pg_lo_import)
PHP_FALIAS(pg_loexport, pg_lo_export, arginfo_pg_lo_export)
#if HAVE_PQCLIENTENCODING
PHP_FALIAS(pg_clientencoding, pg_client_encoding,
arginfo_pg_client_encoding)
PHP_FALIAS(pg_setclientencoding, pg_set_client_encoding,
arginfo_pg_set_client_encoding)

I suppose most pgsql users are pleased these new names and aliases.

It would be nice to do the same for other functions. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Rowan Collins — view source

unread

For example, I've made pg_query() long time ago while there was pg_exec().
http://jp2.php.net/manual/en/function.pg-query.php

At that time, there wasn't a prepared query. Now we have pg_execute()
to execute
prepared query.

I guess not many people consider this was harmful.

It's certainly true that aliases are not automatically a bad idea. There
might have been a bit of confusion when it was introduced and people
thought the functions did different things, but in this case, the old
function probably wasn't something people typed on a day-to-day basis.

I suppose most pgsql users are pleased these new names and aliases.

Actually, most pgsql users have probably never used half of those
functions, and the other half are used once or twice in a rarely-edited
abstraction layer, and if you asked someone how many underscores were in
the names they would look it up in the manual. These are not the kind of
functions usually mentioned regarding general consistency of function
names - the examples given are often widely-used functions like string
and array utilities.

These are going to be used all over the place in shared code, and
applications supporting older versions of PHP will need to carry on
using old names, applications migrating will have to decide if it's
worth finding and replacing them all, and new applications will have to
decide if the new names should be adopted as official coding standards,
based on what other applications the coders are working on.

Adding aliases for cleanup does not worth the effort now. I agree.
However, it does for future. IMHO.

The problem is, that there is no neat dividing line between "short term"
and "long term". One blurs into the other, and different people were
perceive the pace of change differently. A long overlap with multiple
names for everything has its costs, and a short overlap with lots of
breaking changes also has its cost.

Note that the alternative I and others are advocating is not "no
change", but "radical change" - rather than introducing different names
for functions that work in exactly the same way, introduce new ways of
achieving the same thing, with a nicely unified structure. This makes it
a much easier to decide and announce "we're going to use OO-style
strings" (or whatever scheme is invented).

Name collision by adding aliases is not much issue with namespace.

You keep bringing this up, but I for one have never mentioned it as an
issue with adding aliases. My point is entirely about the value and cost
of having multiple names with identical meaning.

I mentioned using namespaces (in the technical sense) as a way of
radically rearranging functions (e.g. array\filter(),
array\sort\callback\associative() but better thought out than that) but
that's nothing to do with name collision really.

Anyone who don't care cleanup, they don't have to care and keep
using old names.

Don't forget that a language needs to be easy to read as well as easy
to write - if one person ignores the new names, but then reads code
using them, that code is harder for them to understand.

In short: there may be particular cases where the advantages of adding
an alias outweigh the disadvantages, but it's by no means automatic, and
doing it across the whole of PHP is not going to automatically be good
for the language's future.

Regards,

--
Rowan Collins
[IMSoP]

10 years ago by Yasuo Ohgaki — view source

unread

Hi Rowan,

On Mon, Jan 27, 2014 at 3:38 AM, Rowan Collins rowan.collins@gmail.comwrote:

For example, I've made pg_query() long time ago while there was pg_exec().
http://jp2.php.net/manual/en/function.pg-query.php

At that time, there wasn't a prepared query. Now we have pg_execute() to
execute
prepared query.

I guess not many people consider this was harmful.

It's certainly true that aliases are not automatically a bad idea. There
might have been a bit of confusion when it was introduced and people
thought the functions did different things, but in this case, the old
function probably wasn't something people typed on a day-to-day basis.

I guess many users don't type native module function names now a days,
since most users are using some kind of framework.

I suppose most pgsql users are pleased these new names and aliases.

Actually, most pgsql users have probably never used half of those
functions, and the other half are used once or twice in a rarely-edited
abstraction layer, and if you asked someone how many underscores were in
the names they would look it up in the manual. These are not the kind of
functions usually mentioned regarding general consistency of function names

the examples given are often widely-used functions like string and array
utilities.

These would be typed by many users.

These are going to be used all over the place in shared code, and
applications supporting older versions of PHP will need to carry on using
old names, applications migrating will have to decide if it's worth finding
and replacing them all, and new applications will have to decide if the new
names should be adopted as official coding standards, based on what other
applications the coders are working on.

I understand this argument. Since we have short release cycle and rather
short life for a release, this is short term disadvantage. They may keep
using aliases functions also.

Adding aliases for cleanup does not worth the effort now. I agree.

However, it does for future. IMHO.

The problem is, that there is no neat dividing line between "short term"
and "long term". One blurs into the other, and different people were
perceive the pace of change differently. A long overlap with multiple names
for everything has its costs, and a short overlap with lots of breaking
changes also has its cost.

Keeping inconsistent names have its cost also.

Note that the alternative I and others are advocating is not "no change",
but "radical change" - rather than introducing different names for
functions that work in exactly the same way, introduce new ways of
achieving the same thing, with a nicely unified structure. This makes it a
much easier to decide and announce "we're going to use OO-style strings"
(or whatever scheme is invented).

It's nice to have them.
Even when we have nice OO style API, old functions will remain forever,
probably.

Name collision by adding aliases is not much issue with namespace.

You keep bringing this up, but I for one have never mentioned it as an
issue with adding aliases. My point is entirely about the value and cost of
having multiple names with identical meaning.

Good!
I realize cost of having aliases also.
The only difference here is you think cost of alias outweigh while I think
cost of inconsistent names outweigh.

I mentioned using namespaces (in the technical sense) as a way of
radically rearranging functions (e.g. array\filter(), array\sort\callback\associative()
but better thought out than that) but that's nothing to do with name
collision really.

Anyone who don't care cleanup, they don't have to care and keep

using old names.

Don't forget that a language needs to be easy to read as well as easy to
write - if one person ignores the new names, but then reads code using
them, that code is harder for them to understand.

IMHO, aliases would not affect readability. Users would understand what

word_wrap() and wordwrap()
htmlspecialchar and html_special_chars()
and so on

means.

I still check correct name see if it has "_" delimited name or not for
rarely used functions.
(I don't use IDE to write PHP code ;)

In short: there may be particular cases where the advantages of adding an

alias outweigh the disadvantages, but it's by no means automatic, and doing
it across the whole of PHP is not going to automatically be good for the
language's future.

I agree that automatic aliasing would not be good.
String and array function names needs more discussion.
GD function names may be aliased automatically, for example.

We should discuses if we are going to add standard name aliases
to module functions or not, perhaps?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Rowan Collins — view source

unread

Yasuo Ohgaki wrote (on 27/01/2014):

I understand this argument. Since we have short release cycle and
rather short life for a release, this is short term disadvantage. They
may keep using aliases functions also.

At the moment, the short release lifetime is rather more theoretical
than proven. PHP 5.3 was released nearly 5 years ago, but some surveys
put 5.2 at a 30% share, e.g.
http://w3techs.com/technologies/details/pl-php/5/all

What's more, the more radically each version changes, the longer it will
take to be adopted, and the more pressure there will be to support older
versions in parallel. (I'm talking here about 3rd parties supporting
their code, not PHP.net supporting the implementation.)

A long overlap with multiple names for everything has its costs,
and a short overlap with lots of breaking changes also has its cost.

Keeping inconsistent names have its cost also.

A good point.

IMHO, aliases would not affect readability. Users would understand what

word_wrap() and wordwrap()
htmlspecialchar and html_special_chars()
and so on

means.

But they might wonder if there was a difference between them,
particularly if the aliases are more distinct (e.g. count() vs sizeof()).

I agree that automatic aliasing would not be good.
String and array function names needs more discussion.
GD function names may be aliased automatically, for example.

We should discuses if we are going to add standard name aliases
to module functions or not, perhaps?

Yes, I think per-module / extension is the way to go - as with the pg_*
functions you mentioned earlier.

It can then be proposed that a certain module be converted to OO (as
happened with DateTime), another tidied up to have a consistent naming
structure, and another left alone until more "interesting" changes are
being made to it.

Regards,

Rowan Collins
[IMSoP]

10 years ago by Yasuo Ohgaki — view source

unread

Hi Rowan,

On Tue, Jan 28, 2014 at 3:13 AM, Rowan Collins rowan.collins@gmail.comwrote:

IMHO, aliases would not affect readability. Users would understand what

word_wrap() and wordwrap()
htmlspecialchar and html_special_chars()
and so on

means.

But they might wonder if there was a difference between them, particularly
if the aliases are more distinct (e.g. count() vs sizeof()).

I agree. Completely different name could be pain.

I agree that automatic aliasing would not be good.

String and array function names needs more discussion.
GD function names may be aliased automatically, for example.

We should discuses if we are going to add standard name aliases
to module functions or not, perhaps?

Yes, I think per-module / extension is the way to go - as with the pg_*
functions you mentioned earlier.

It can then be proposed that a certain module be converted to OO (as
happened with DateTime), another tidied up to have a consistent naming
structure, and another left alone until more "interesting" changes are
being made to it.

String and array function alias discussion would be difficult to reach a
consensus.
Let's separate discussion and concentrate module function at first.

We have new function "apache_request/response_headers" and "getallheaders"
in "CLI" server.

const zend_function_entry server_additional_functions[] = {
PHP_FE(cli_set_process_title, arginfo_cli_set_process_title)
PHP_FE(cli_get_process_title, arginfo_cli_get_process_title)
PHP_FE(apache_request_headers, arginfo_no_args)
PHP_FE(apache_response_headers, arginfo_no_args)
PHP_FALIAS(getallheaders, apache_request_headers, arginfo_no_args)
{NULL, NULL, NULL}
};

We should avoid these kind of naming also.

I'll check modules and list candidates in the RFC.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Levi Morrison — view source

unread

On Thu, Jan 23, 2014 at 6:11 PM, Larry Garfield larry@garfieldtech.comwrote

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

This is a completely honest, sincere question: Why should the language
itself use an object-oriented design for everything it provides?

10 years ago by Christian Stoller — view source

unread

On Thu, Jan 23, 2014 at 6:11 PM, Larry Garfield larry@garfieldtech.comwrote

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

This is a completely honest, sincere question: Why should the language
itself use an object-oriented design for everything it provides?

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

Or: $keys = array_keys($array);

To: $keys = $array->keys();

I think it looks a lot cleaner, self-explaining, shorter, and if you are used to write OOP, it fits better to the rest of your code.

10 years ago by Stas Malyshev — view source

unread

Hi!

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

Or: $keys = array_keys($array);

To: $keys = $array->keys();

I think it looks a lot cleaner, self-explaining, shorter, and if you
are used to write OOP, it fits better to the rest of your code.

I think it has very little difference and entirely a matter of personal
taste. But the thing is - nobody prevents anybody from writing an
extension that does string ops or array ops as an object. Yet it did not
happen in last 10 years, AFAIK.

--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Yasuo Ohgaki — view source

unread

Hi Stas,

On Thu, Jan 30, 2014 at 3:21 AM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

Or: $keys = array_keys($array);

To: $keys = $array->keys();

I think it looks a lot cleaner, self-explaining, shorter, and if you
are used to write OOP, it fits better to the rest of your code.

I think it has very little difference and entirely a matter of personal
taste. But the thing is - nobody prevents anybody from writing an
extension that does string ops or array ops as an object. Yet it did not
happen in last 10 years, AFAIK.

It was said and didn't happen...
I would like to make session/pgsql a class some day. I don't know
when it will be, since I'm satisfied with current implementation.

Besides OO API, we should keep function API. It may be confusing
to users if OO and function name differs.

It may be good to add proper aliases now and when it is needed,
so that we don't have

const zend_function_entry server_additional_functions[] = {
PHP_FE(cli_set_process_title, arginfo_cli_set_process_title)
PHP_FE(cli_get_process_title, arginfo_cli_get_process_title)
PHP_FE(apache_request_headers, arginfo_no_args)
PHP_FE(apache_response_headers, arginfo_no_args)
PHP_FALIAS(getallheaders, apache_request_headers, arginfo_no_args)
{NULL, NULL, NULL}
};

this kind of naming anymore.

I understand reason why, but new 'apache_()' function in cli server
does not make much sense to me. For this case, I suggest 'sapi_()'
or 'http_*()' as main name and others as aliases.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Lester Caine — view source

unread

Stas Malyshev wrote:

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

I think it looks a lot cleaner, self-explaining, shorter, and if you
are used to write OOP, it fits better to the rest of your code.

I think it has very little difference and entirely a matter of personal
taste. But the thing is - nobody prevents anybody from writing an
extension that does string ops or array ops as an object. Yet it did not
happen in last 10 years, AFAIK.

Isn't this just a mater of the increased overheads demanded by defining $str as
a 'string object' over just a simple 'string'. It amasses me at times just how
big some of the objects created are simply to handle what is essentially just a
simple array of strings and the like. Just what overhead is being created and
how much faster would things work if we returned to a less 'object based'
structure? The majority of the processing I'm doing would be much faster if the
database simply returned an array of variables ...

--
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 Andrea Faulds — view source

unread

Isn't this just a mater of the increased overheads demanded by defining
$str as a 'string object' over just a simple 'string'. It amasses me at
times just how big some of the objects created are simply to handle what
is essentially just a simple array of strings and the like. Just what
overhead is being created and how much faster would things work if we
returned to a less 'object based' structure? The majority of the
processing I'm doing would be much faster if the database simply
returned an array of variables ...

There would be no overhead, no objects would be created.

--
Andrea Faulds
http://ajf.me/

10 years ago by Nikita Popov — view source

unread

On Wed, Jan 29, 2014 at 7:21 PM, Stas Malyshev smalyshev@sugarcrm.comwrote:

Hi!

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

Or: $keys = array_keys($array);

To: $keys = $array->keys();

I think it looks a lot cleaner, self-explaining, shorter, and if you
are used to write OOP, it fits better to the rest of your code.

I think it has very little difference and entirely a matter of personal
taste. But the thing is - nobody prevents anybody from writing an
extension that does string ops or array ops as an object. Yet it did not
happen in last 10 years, AFAIK.

https://github.com/nikic/scalar_objects

Also, the point of doing this is not the nicer syntax, but the opportunity
to improve the APIs in a reasonable fashion (no countless aliases).

Nikita

10 years ago by Yasuo Ohgaki — view source

unread

Hi all,

Hi!

Compare: $str = str_replace('-', '_', $str);

To: $str = $str->replace('-', '_');

Or: $keys = array_keys($array);

To: $keys = $array->keys();

I think it looks a lot cleaner, self-explaining, shorter, and if you
are used to write OOP, it fits better to the rest of your code.

I think it has very little difference and entirely a matter of personal
taste. But the thing is - nobody prevents anybody from writing an
extension that does string ops or array ops as an object. Yet it did not
happen in last 10 years, AFAIK.

https://github.com/nikic/scalar_objects

Also, the point of doing this is not the nicer syntax, but the opportunity
to improve the APIs in a reasonable fashion (no countless aliases).

and/or

https://wiki.php.net/rfc/autoboxing

I think aliases would not be countless.
It could be added matter of hours for all functions in php-src.
Discussion for choosing proper name could be timeless :)

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

10 years ago by Stas Malyshev — view source

unread

Hi!

https://github.com/nikic/scalar_objects

Also, the point of doing this is not the nicer syntax, but the
opportunity to improve the APIs in a reasonable fashion (no countless
aliases).

That may be a good start for it (and I like the concept of enabling ->
on scalars) but the other part of the work is to create the consistent
API that would be so good people would actually drop the old ones and
switch to it, despite the cost involved.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

10 years ago by Lester Caine — view source

unread

Levi Morrison wrote:

If we're going to do anything, be aggressive and far-reaching with it.

Build a proper language-level OOP design for string/array manipulation.

This is a completely honest, sincere question: Why should the language
itself use an object-oriented design for everything it provides?

Well personally I'll continue to use the current functions. It was more a
suggestion to free up the pressure on changing them at all. Let the people who
object to the format have an alternative the rest of us can ignore ;)

--
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 Thu, Jan 23, 2014 at 6:11 PM, Larry Garfield larry@garfieldtech.comwrote

If we're going to do anything, be aggressive and far-reaching with it.
Build a proper language-level OOP design for string/array manipulation.

This is a completely honest, sincere question: Why should the language
itself use an object-oriented design for everything it provides?

Well, the reason that's most relevant to this discussion is that it's an
excuse for a clear distinction between the old and the new.

For instance: join() is an alias of implode(), which can take arguments
in either order, or take only one argument; split() is a deprecated
regex function not to be confused with explode(), which always takes (at
least) 2 arguments, in a set order. Those function names have got to
retain at least some of their behaviour - or be removed permanently -
for as long as we still consider it the same language.

However, with an "object-like" string interface you have a completely
blank slate to design a clean interface alongside the old functions:
$string->split('x')->join('y') perhaps.

Another inconsistency often complained about is argument order; for a
lot of operations, one parameter is the natural "subject" of the action,
so you could have $array->map($function), $array->filter($function)
rather than array_map($function, $array) and array_filter($array,
$function).

The downside, I admit, is it might "feel less like PHP". But there's a
lot of object-oriented PHP out there where this would look quite at home.

The only other way I can think of making a clean break from the messes
in the current global namespace is to make new namespaced versions of
the basic functions, like string\split, array\join, etc. Maybe even put
all the existing functions into a legacy\ namespace which you could
"use", although that might be a bit of a pain to work with. But unlike
OO, that leaves us with potentially more to type for the new names than
the old, which seems a shame.

Basically, adding OO-style could feel like a proper tidy-up, rather than
just re-painting a few bits that are easy to reach.

--
Rowan Collins
[IMSoP]

[PHP6] Function name consistency

Regards, Florin

Regards,

-- Lester Caine - G8HFL

That may be a good start for it (and I like the concept of enabling -> on scalars) but the other part of the work is to create the consistent API that would be so good people would actually drop the old ones and switch to it, despite the cost involved.

-- Lester Caine - G8HFL

Regards,
Florin

--
Lester Caine - G8HFL

That may be a good start for it (and I like the concept of enabling ->
on scalars) but the other part of the work is to create the consistent
API that would be so good people would actually drop the old ones and
switch to it, despite the cost involved.

--
Lester Caine - G8HFL