Deprecation ideas for PHP 8

5 years ago by Girgias — view source

unread

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:

PHP Info/Option functions:

php_sapi_name (use PHP_SAPI constant)
phpversion (use PHP_VERSION constant)
php_uname (use PHP_OS constant)

Classes/Objects functions:

is_a (use instanceof operator)
is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)

Function handling functions:

call_user_func (invoke directly)
call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6
forward_static_call (same reason as call_user_func)
forward_static_cal_array (same reason as call_user_func_array)
func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))
func_get_args (same reason as func_get_arg)
func_num_args (same reason as func_get_arg)

Variable handling functions:
Aliases:

is_double
is_integer
is_long
is_real (already in the deprecation draft for PHP 7.4)

Setting var type (can use variable casting nowadays):

boolval
doubleval
floatval
intval (for arbitrary base change there exists the math function
base_convert)
settype
strval
gettype (more on this later [1])

String functions aliases:

chop (alias of rtrim)
join (alias of implode)
strchr (alias of strstr)

Maths functions aliases:

getrandmax
rand (use mt_rand instead)
srand (alias of mt_srand as of PHP 7.1)

Filesystem aliases:

diskfreespace — Alias of disk_free_space
fputs — Alias of fwrite
is_writeable — Alias of is_writable
set_file_buffer — Alias of stream_set_write_buffer

Old signatures:

implode (historical signature)

Controversial idea:

deprecate array function creation (array())

[1] About gettype:
The gettype function is really convenient as it can easily provide the type
of a variable without
needed to use a bunch of conditional checks, it can even as of PHP 7.2
signal if a resource
has been closed.
However, it still returns "double" for a float due to historical reasons
and it seems quite
complicated to change how it operates currently.
I have thought of two possible ideas which would allow PHP to return float
instead of double:

First, create a new reflection class ReflectionVar:
This feels even to me like a bit of an overkill more so that something
simple (a unique function
call) would require an object instantiation. But it can allow some
extensions such as the
Reflection for Reference RFC proposed by nikic (c.f.
https://wiki.php.net/rfc/reference_reflection)

Second, create a new function get_var_type($mixed):
This would behave exactly the same as the current implementation with the
one difference that
it would return 'float' instead of 'double'. This new function name would
be more consistent with how the other functions are named (namely
get_resource_type).
This implementation has the benefit of keeping it simple but will probably
duplicate code within the engine.

Just to remind these are only ideas and feedback is wholeheartedly
welcomed. I also probably
missed some more functions which could be deprecated as of PHP 8 but I feel
this covers
already a large portion.

Best regards

George P. Banyard

5 years ago by Stephen Reay — view source

unread

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:

PHP Info/Option functions:

php_sapi_name (use PHP_SAPI constant)

phpversion (use PHP_VERSION constant)

php_uname (use PHP_OS constant)

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)

Function handling functions:

call_user_func (invoke directly)

call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6

forward_static_call (same reason as call_user_func)

forward_static_cal_array (same reason as call_user_func_array)

func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))

func_get_args (same reason as func_get_arg)

func_num_args (same reason as func_get_arg)

Variable handling functions:
Aliases:

is_double

is_integer

is_long

is_real (already in the deprecation draft for PHP 7.4)

Setting var type (can use variable casting nowadays):

boolval

doubleval

floatval

intval (for arbitrary base change there exists the math function
base_convert)

settype

strval

gettype (more on this later [1])

String functions aliases:

chop (alias of rtrim)

join (alias of implode)

strchr (alias of strstr)

Maths functions aliases:

getrandmax

rand (use mt_rand instead)

srand (alias of mt_srand as of PHP 7.1)

Filesystem aliases:

diskfreespace — Alias of disk_free_space

fputs — Alias of fwrite

is_writeable — Alias of is_writable

set_file_buffer — Alias of stream_set_write_buffer

Old signatures:

implode (historical signature)

Controversial idea:

deprecate array function creation (array())

[1] About gettype:
The gettype function is really convenient as it can easily provide the type
of a variable without
needed to use a bunch of conditional checks, it can even as of PHP 7.2
signal if a resource
has been closed.
However, it still returns "double" for a float due to historical reasons
and it seems quite
complicated to change how it operates currently.
I have thought of two possible ideas which would allow PHP to return float
instead of double:

First, create a new reflection class ReflectionVar:
This feels even to me like a bit of an overkill more so that something
simple (a unique function
call) would require an object instantiation. But it can allow some
extensions such as the
Reflection for Reference RFC proposed by nikic (c.f.
https://wiki.php.net/rfc/reference_reflection)

Second, create a new function get_var_type($mixed):
This would behave exactly the same as the current implementation with the
one difference that
it would return 'float' instead of 'double'. This new function name would
be more consistent with how the other functions are named (namely
get_resource_type).
This implementation has the benefit of keeping it simple but will probably
duplicate code within the engine.

Just to remind these are only ideas and feedback is wholeheartedly
welcomed. I also probably
missed some more functions which could be deprecated as of PHP 8 but I feel
this covers
already a large portion.

Best regards

George P. Banyard

is_subclass_of allows checking string class names, instanceof (AFAIK) does not.

5 years ago by Girgias — view source

unread

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the
same
class must not be used)

is_subclass_of allows checking string class names, instanceof (AFAIK) does
not.

Good catch, just checked and it's indead the case that instanceof can't
check string class names:
https://3v4l.org/DkMC4

George P. Banyard

5 years ago by mtkocak@gmail.com — view source

unread

Can we also add strange function names without any naming conventions to
this list? Without undersore: strcspn, With underscore: str_repeat, chain
of abrevs: strnatcasecmp. Similar namings do exist for array functions
either.

Cheers,
Midori

On Tue, 22 Jan 2019 at 21:48, Stephen Reay php-lists@koalephant.com
wrote:

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the
same
class must not be used)

is_subclass_of allows checking string class names, instanceof (AFAIK)
does
not.

Good catch, just checked and it's indead the case that instanceof can't
check string class names:
https://3v4l.org/DkMC4

George P. Banyard

5 years ago by Yasuo Ohgaki — view source

unread

Can we also add strange function names without any naming conventions to
this list? Without undersore: strcspn, With underscore: str_repeat, chain
of abrevs: strnatcasecmp. Similar namings do exist for array functions
either.

Candidates are these
https://wiki.php.net/rfc/consistent_function_names

From previous discussion, I think it would be better to keep both PHP and
POSIX names.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

5 years ago by Rowan Collins — view source

unread

Can we also add strange function names without any naming conventions to
this list

In short, no. I wish we had an FAQ where we could avoid recapping the
arguments around this, but it has come up many times, and the conclusion
has always been that it's never going to happen.

It would be great if we could invent a time machine and design the
language differently, but it's too late now, there is just too much code
out there to "fix".

Regards,

--
Rowan Collins
[IMSoP]

5 years ago by Peter Kokot — view source

unread

Hello,

Can we also add strange function names without any naming conventions to
this list

In short, no. I wish we had an FAQ where we could avoid recapping the
arguments around this, but it has come up many times, and the conclusion
has always been that it's never going to happen.

It would be great if we could invent a time machine and design the
language differently, but it's too late now, there is just too much code
out there to "fix".

This now also means that PHP is making its inconsistency a fact and it
will never ever be able to reach the consistency level it should be
at... Specially, if more and more people believe this. I'm not sure
this is the good approach in programming and neither is really a fact,
but who am I to judge this state now. It would be good to avoid having
FAQs and appendixes in coding standards for those
function_name_ext_SomethingElseOutofblue() cases so that it might be
still achieved one day.

--
Peter Kokot

5 years ago by Rowan Collins — view source

unread

This now also means that PHP is making its inconsistency a fact

The inconsistency IS a fact, and has been for more than 20 years. This
isn't some new policy, banning something that used to be possible, it's
a summary of something that's been discussed over and over again, and
always reached the same conclusion.

The unfortunate truth is that the only way to truly fix most of these
problems would be to create a completely new language, like Perl6; or at
least a complete rewrite, like Python 3. As those two examples show, the
result would be effort and community split between two forks, one that
runs all the millions of PHP applications already written, and one that
is theoretically nicer, but runs none of that old code. That just isn't
a price worth paying.

Regards,

--
Rowan Collins
[IMSoP]

5 years ago by Peter Kokot — view source

unread

This now also means that PHP is making its inconsistency a fact

The inconsistency IS a fact, and has been for more than 20 years. This
isn't some new policy, banning something that used to be possible, it's
a summary of something that's been discussed over and over again, and
always reached the same conclusion.

The unfortunate truth is that the only way to truly fix most of these
problems would be to create a completely new language, like Perl6; or at
least a complete rewrite, like Python 3. As those two examples show, the
result would be effort and community split between two forks, one that
runs all the millions of PHP applications already written, and one that
is theoretically nicer, but runs none of that old code. That just isn't
a price worth paying.

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Not that it is not possible to do this, but too many people promote
this state as not possible to change. I didn't put too much effort to
make a list of all the changes to an extend as is nicely done in the
RFC but maybe enough would be renaming functions and alias them
properly from major/minor release version to version and furthermore
deprecate the aliases, so they match the pattern suggested for PHP
vanilla functions [2]. Not to mention really good ideas from the past
discussions with namespacing functions and similar approaches...

But, yes... Without proper will or motivation from key people who
could change this it will stay in the inconsistent state and we all
accept it as is. Specially in discussions about a major release where
BC could be done.

[1] https://wiki.php.net/rfc/consistent_function_names
[2] https://github.com/php/php-src/blob/master/CODING_STANDARDS

--
Peter Kokot

5 years ago by Rowan Collins — view source

unread

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Hi,

I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
the fundamental problem: the effort needed is not on the part of a few
volunteers changing the language, it is effort by every single user of the
language, rewriting every single PHP program ever written.

WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
7.3, released a couple of months ago; one of their biggest challenges in
raising that bar is that they, too, have to persuade a community (the theme
and plugin authors) to change their code to match. That should give you
some idea of how long old and new names would have to exist side by side,
while we waited for everyone to rewrite all their code, and meanwhile, the
language would be even more inconsistent, because there would be extra
ways of writing the same thing.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Benjamin Morel — view source

unread

Please forgive my stubborness, too. I fail to see how WordPress supporting
PHP versions that have been EOL for YEARS can be of any help to the
community? These versions may have unpatched security holes, and
encouraging users to keep using them is a disfavour to the community IMO,
which can only delay adoption of newer versions, and lead to an even more
painful upgrade path when you have to upgrade N versions at once. My stance
on this is that projects written in PHP have to evolve together with the
language, and I'm personally not surprised to have to rewrite a few things
whenever a major PHP version is released (and I do maintain quite a number
of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
my projects towards a more consistent PHP language.

That being said, I know this opinion is a minority on this list, so let's
put it aside for a moment.

Now what prevents PHP from adding consistent function names / APIs, and
deprecating the older ones? We can keep the old ones for 10 more years if
you wish, but at least new PHP code can start using the "correct" ones, and
progressively the share of PHP code out there using the old ones should
progressively get lower over the years, up to the point where we could
eventually decide that it's not worth keeping them. The thing is, if you
never start, the situation will never improve.

You know the proverb: The best time to plant a tree was 20 years ago. The
second best time is now.

Ben

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Hi,

I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
the fundamental problem: the effort needed is not on the part of a few
volunteers changing the language, it is effort by every single user of the
language, rewriting every single PHP program ever written.

WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
7.3, released a couple of months ago; one of their biggest challenges in
raising that bar is that they, too, have to persuade a community (the theme
and plugin authors) to change their code to match. That should give you
some idea of how long old and new names would have to exist side by side,
while we waited for everyone to rewrite all their code, and meanwhile, the
language would be even more inconsistent, because there would be extra
ways of writing the same thing.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Rowan Collins — view source

unread

On Thu, 31 Jan 2019 at 10:53, Benjamin Morel benjamin.morel@gmail.com
wrote:

Please forgive my stubborness, too. I fail to see how WordPress supporting
PHP versions that have been EOL for YEARS can be of any help to the
community?

I agree, it probably doesn't help the community; but it happens, both in
open source projects, and in the many private code bases which are written
in PHP. The more breaking changes we make in the language, the more
likely it is that people will stay on old versions, where their code works
without modification, and have a negative opinion of upgrades.

Now what prevents PHP from adding consistent function names / APIs, and
deprecating the older ones? We can keep the old ones for 10 more years if
you wish, but at least new PHP code can start using the "correct" ones, and
progressively the share of PHP code out there using the old ones should
progressively get lower over the years, up to the point where we could
eventually decide that it's not worth keeping them.

The problem comes if the share using the old names doesn't decline enough
(and how would we even know?). What if people's muscle memory, their coding
standards, their need for progressive compatibility, their tools, the
tutorials they follow, the code snippets they copy, all make it easier to
just keep using the old names? Then our "deprecation" means nothing, and we
are stuck with a long list of aliases to maintain, and people learning the
language scratching their heads at inconsistent examples.

To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they want to upgrade their code to use it, although it takes
us close to "completely new language" territory.

If we can persuade every user of PHP that the change is bringing them a
real benefit to outweigh the cost of re-writing and re-learning, then we
can make grand changes to the language; I don't think moving underscores
around will ever do that.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Benjamin Morel — view source

unread

The problem comes if the share using the old names doesn't decline
enough (and how would we even know?).

We can't survey private projects, but we can run automated analysis tools
on a large number of open-source projects available on GitHub, and compile
statistics from them. I'd be happy to work on such a tool, should it be
useful some day.

What if people's muscle memory, their coding standards, their need for
progressive compatibility, their tools, the tutorials they follow, the code
snippets they copy, all make it easier to just keep using the old names?
Then our "deprecation" means nothing, and we are stuck with a long list of
aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they want to upgrade their code to use it...

I do agree with you on that point: I'd rather offer brand new APIs, rather
than just fixing naming inconsistencies. There is so much more than fixing
naming inconsistencies. The error handling, in particular, should be given
some love, by throwing exceptions everywhere, instead of returning false /
triggering warnings. And I would love, too, either your "scalar methods"
approach, or array being an object with built-in map/filter/reduce...

... although it takes us close to "completely new language" territory.

Maybe not, if this can be done in a mostly BC way.

On Thu, 31 Jan 2019 at 10:53, Benjamin Morel benjamin.morel@gmail.com
wrote:

Please forgive my stubborness, too. I fail to see how WordPress
supporting PHP versions that have been EOL for YEARS can be of any help to
the community?

I agree, it probably doesn't help the community; but it happens, both in
open source projects, and in the many private code bases which are written
in PHP. The more breaking changes we make in the language, the more
likely it is that people will stay on old versions, where their code works
without modification, and have a negative opinion of upgrades.

Now what prevents PHP from adding consistent function names / APIs, and
deprecating the older ones? We can keep the old ones for 10 more years if
you wish, but at least new PHP code can start using the "correct" ones, and
progressively the share of PHP code out there using the old ones should
progressively get lower over the years, up to the point where we could
eventually decide that it's not worth keeping them.

The problem comes if the share using the old names doesn't decline
enough (and how would we even know?). What if people's muscle memory, their
coding standards, their need for progressive compatibility, their tools,
the tutorials they follow, the code snippets they copy, all make it easier
to just keep using the old names? Then our "deprecation" means nothing, and
we are stuck with a long list of aliases to maintain, and people learning
the language scratching their heads at inconsistent examples.

To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they want to upgrade their code to use it, although it takes
us close to "completely new language" territory.

If we can persuade every user of PHP that the change is bringing them a
real benefit to outweigh the cost of re-writing and re-learning, then we
can make grand changes to the language; I don't think moving underscores
around will ever do that.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Rowan Collins — view source

unread

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel benjamin.morel@gmail.com
wrote:

What if people's muscle memory, their coding standards, their need for
progressive compatibility, their tools, the tutorials they follow, the code
snippets they copy, all make it easier to just keep using the old names?
Then our "deprecation" means nothing, and we are stuck with a long list
of aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

Deprecation notices won't change people's desire to change their code. If
you raised a deprecation notice for every call to, say "htmlspecialchars",
the only result would be people turning off deprecation notices, and
missing more important deprecations.

... although it takes us close to "completely new language"
territory.

Maybe not, if this can be done in a mostly BC way.

It wasn't the BC I was worrying about there, but the possibility that
projects would adopt one style or the other, and readers coming from an
"old-style" project might find the code in a "new-style" project rather
alien. In a worst case scenario, it would feel like we had two languages
interoperating on the same runtime, like when HHVM hosted both PHP and
Hack. It's not inevitable, though, just a risk to think about if we ever
get to that position.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Benjamin Morel — view source

unread

Deprecation notices won't change people's desire to change their code.
If you raised a deprecation notice for every call to, say
"htmlspecialchars", the only result would be people turning off deprecation
notices, and missing more important deprecations.

You have a point here. Couldn't we add a "deprecated log" feature, that
would log each deprecated function only once? At least we could leave an
app running for some time, and get a curated list of deprecated features
from the deprecated log.

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel benjamin.morel@gmail.com
wrote:

What if people's muscle memory, their coding standards, their need for
progressive compatibility, their tools, the tutorials they follow, the code
snippets they copy, all make it easier to just keep using the old names?
Then our "deprecation" means nothing, and we are stuck with a long list
of aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

Deprecation notices won't change people's desire to change their code.
If you raised a deprecation notice for every call to, say
"htmlspecialchars", the only result would be people turning off deprecation
notices, and missing more important deprecations.

... although it takes us close to "completely new language"
territory.

Maybe not, if this can be done in a mostly BC way.

It wasn't the BC I was worrying about there, but the possibility that
projects would adopt one style or the other, and readers coming from an
"old-style" project might find the code in a "new-style" project rather
alien. In a worst case scenario, it would feel like we had two languages
interoperating on the same runtime, like when HHVM hosted both PHP and
Hack. It's not inevitable, though, just a risk to think about if we ever
get to that position.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Kalle Sommer Nielsen — view source

unread

Den fre. 1. feb. 2019 kl. 12.34 skrev Benjamin Morel benjamin.morel@gmail.com:

You have a point here. Couldn't we add a "deprecated log" feature, that
would log each deprecated function only once? At least we could leave an
app running for some time, and get a curated list of deprecated features
from the deprecated log.

I would oppose such a feature as it would make deprecations even more
redundant than disabling them. While they are annoying, they are also
a helpful message to inform our users that this functionality will not
be around, blindly ignoring it and further more giving it its own log
file that doesn't grow nearly as much seems like a bad way to solve
this.

--
regards,

Kalle Sommer Nielsen
kalle@php.net

5 years ago by mtkocak@gmail.com — view source

unread

Totally agree with this. The new and old can exist both. We should be open
to change.

Please forgive my stubborness, too. I fail to see how WordPress supporting
PHP versions that have been EOL for YEARS can be of any help to the
community? These versions may have unpatched security holes, and
encouraging users to keep using them is a disfavour to the community IMO,
which can only delay adoption of newer versions, and lead to an even more
painful upgrade path when you have to upgrade N versions at once. My stance
on this is that projects written in PHP have to evolve together with the
language, and I'm personally not surprised to have to rewrite a few things
whenever a major PHP version is released (and I do maintain quite a number
of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
my projects towards a more consistent PHP language.

That being said, I know this opinion is a minority on this list, so let's
put it aside for a moment.

Now what prevents PHP from adding consistent function names / APIs, and
deprecating the older ones? We can keep the old ones for 10 more years if
you wish, but at least new PHP code can start using the "correct" ones, and
progressively the share of PHP code out there using the old ones should
progressively get lower over the years, up to the point where we could
eventually decide that it's not worth keeping them. The thing is, if you
never start, the situation will never improve.

You know the proverb: The best time to plant a tree was 20 years ago. The
second best time is now.

Ben

On Thu, 31 Jan 2019 at 11:30, Rowan Collins rowan.collins@gmail.com
wrote:

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Hi,

I'm sorry if I sound stubborn, but I have yet to see a reasonable answer
to
the fundamental problem: the effort needed is not on the part of a few
volunteers changing the language, it is effort by every single user of
the
language, rewriting every single PHP program ever written.

WordPress officially supports both PHP 5.2, released 13 years ago, and
PHP
7.3, released a couple of months ago; one of their biggest challenges in
raising that bar is that they, too, have to persuade a community (the
theme
and plugin authors) to change their code to match. That should give you
some idea of how long old and new names would have to exist side by side,
while we waited for everyone to rewrite all their code, and meanwhile,
the
language would be even more inconsistent, because there would be extra
ways of writing the same thing.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Yasuo Ohgaki — view source

unread

On Thu, Jan 31, 2019 at 7:30 PM Rowan Collins rowan.collins@gmail.com
wrote:

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Hi,

I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
the fundamental problem: the effort needed is not on the part of a few
volunteers changing the language, it is effort by every single user of the
language, rewriting every single PHP program ever written.

WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
7.3, released a couple of months ago; one of their biggest challenges in
raising that bar is that they, too, have to persuade a community (the theme
and plugin authors) to change their code to match. That should give you
some idea of how long old and new names would have to exist side by side,
while we waited for everyone to rewrite all their code, and meanwhile, the
language would be even more inconsistent, because there would be extra
ways of writing the same thing.

Hi,

Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE) names.
So there wouldn't be compatibility issues for CODING_STANDARD names.

Christoph suggests namespace for renaming function. This works also.
If namespace is used, it is better to have "PHP" namespace to keep user
namespace clean. IMO.
e.g. PHP\BC\add()
This creates yet another inconsistency with existing modules, though.

Bottom line is almost all developers dislike inconsistent names, prefer
to enter extra few chars.

Consistent name isn't big deal, but keeping inconsistent names for good
doesn't sound nice.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

5 years ago by Rowan Collins — view source

unread

Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE)
names.
So there wouldn't be compatibility issues for CODING_STANDARD names.

I think this would be the worst of both worlds. We would have to
permanently document two different names for every function, examples
(outside of php.net) would still have the old names in, people would
disagree about which to use, and the situation would be more confusing to
new users, not less. This already happens with count() vs sizeof() - people
get used to one or the other, and are confused when they see the other in
someone else's code.

Bottom line is almost all developers dislike inconsistent names, prefer
to enter extra few chars.

I think almost all developers would like to spend their effort making
material improvements to the robustness or functionality of their code.
That might include replacing htmlspecialchars with a smarter escaping or
"taint" tracking system; but it woudln't include renaming it in all their
code bases, or debating which of two valid names to use in a new codebase.

Let's focus our effort on writing improved features, and giving them good
names, and if that means some of the older functions become less necessary,
that's a bonus.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Christoph M. Becker — view source

unread

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Not that it is not possible to do this, but too many people promote
this state as not possible to change. I didn't put too much effort to
make a list of all the changes to an extend as is nicely done in the
RFC but maybe enough would be renaming functions and alias them
properly from major/minor release version to version and furthermore
deprecate the aliases, so they match the pattern suggested for PHP
vanilla functions [2]. Not to mention really good ideas from the past
discussions with namespacing functions and similar approaches...

But, yes... Without proper will or motivation from key people who
could change this it will stay in the inconsistent state and we all
accept it as is. Specially in discussions about a major release where
BC could be done.

[1] https://wiki.php.net/rfc/consistent_function_names
[2] https://github.com/php/php-src/blob/master/CODING_STANDARDS

In my opinion, there is no gain in renaming bcadd() to bc_add(), for
instance. A namespaced variant BC\add() might be an improvement, but
likely it should rather be BCNumber::plus() (also overloading the +
operator). See also the closely related discussion regarding renaming
the image functions: https://externals.io/message/101050.

--
Christoph M. Becker

5 years ago by Yasuo Ohgaki — view source

unread

Hi Girgias

It seems good list in general.
There would not be issues marking them as deprecated.
"Deprecation" means "Soft deprecation", correct?

Removing these aliases from PHP 8 is not good idea.
Aliases should be removed when nobody cares about these aliases.

For example, pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

5 years ago by Girgias — view source

unread

Hi Girgias

It seems good list in general.
There would not be issues marking them as deprecated.
"Deprecation" means "Soft deprecation", correct?

Removing these aliases from PHP 8 is not good idea.
Aliases should be removed when nobody cares about these aliases.

For example, pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hello Yasuo Ohgaki.

By Deprecation, I was indeed meaning that as of PHP 8 these function should
throw
E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
time
for people to adapt and upgrade their codebase.

Best regards

George P. Banyard

5 years ago by Yasuo Ohgaki — view source

unread

Hi Girgias

It seems good list in general.
There would not be issues marking them as deprecated.
"Deprecation" means "Soft deprecation", correct?

Removing these aliases from PHP 8 is not good idea.
Aliases should be removed when nobody cares about these aliases.

For example, pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hello Yasuo Ohgaki.

By Deprecation, I was indeed meaning that as of PHP 8 these function
should throw
E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
time
for people to adapt and upgrade their codebase.

This is good approach, too.
The alias system does not allow to get currently called function name w/o
overhead, AFAIK. i.e. It simply calls defined functions.

Perhaps, add

PHP_FALIAS_DEPRECATED()

for it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

5 years ago by Girgias — view source

unread

Hi Girgias

It seems good list in general.
There would not be issues marking them as deprecated.
"Deprecation" means "Soft deprecation", correct?

Removing these aliases from PHP 8 is not good idea.
Aliases should be removed when nobody cares about these aliases.

For example, pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

Hello Yasuo Ohgaki.

By Deprecation, I was indeed meaning that as of PHP 8 these function
should throw
E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
time
for people to adapt and upgrade their codebase.

This is good approach, too.
The alias system does not allow to get currently called function name w/o
overhead, AFAIK. i.e. It simply calls defined functions.

Perhaps, add

PHP_FALIAS_DEPRECATED()

for it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

I'm all for it if it reduces overhead.

Best regards

George P. Banyard

5 years ago by Markus Fischer — view source

unread

Hi,

- phpversion (use `PHP_VERSION` constant)

The function takes an optional argument string $extension, what is the
replacement for that?

- intval (for arbitrary base change there exists the math function
base_convert)

I've seen and myself use the following construct a lot to "quickly"
convert data within an array:

$data = array_map('intval', $data);

It's really practical because I don't have to write a (more verbose)
closure.

I'd argue this applies to the other *val calls too.

- join (alias of implode)

Old signatures:

- implode (historical signature)

Is there a correlation here why you mention the alias join and the
actual function implode? I hope you would want to leave either in the
language :-)

cheers,

Markus

5 years ago by Claude Pache — view source

unread

settype

AFAICS, there is no easy replacement for settype(). If the second argument is a string literal, you can use type coercion + assignment at the price of duplicating the occurrence of the first argument. If the second argument is not known at compile time, you have to resort to a switch statement or something similar.

deprecate array function creation (array())

Here, I was really wondering why you didn’t mention function-like destructuring as well (list()). (Not that I think it is a good idea.)

—Claude

5 years ago by Jani Ollikainen — view source

unread

Hi,

The arguments why to deprecate didn't seem much more than, this maybe could be deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?

But some comments that I didn't notice in others.

php_uname (use PHP_OS constant)

PHP_OS is php_uname('s'), how about rest:

mode

mode is a single character that defines what information is returned:

    'a': This is the default. Contains all modes in the sequence "s n r v m".
    's': Operating system name. eg. FreeBSD.
    'n': Host name. eg. localhost.example.com.
    'r': Release name. eg. 5.1.2-RELEASE.
    'v': Version information. Varies a lot between operating systems.
    'm': Machine type. eg. i386.

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)

Both these have $allow_string

Function handling functions:

call_user_func (invoke directly)

Yes, they give a little performance hit, but I still kind of like them. Like if we think the following, I think I would prefer call_user_func for syntax.

class PREA {
public function AB() {
echo "HELLO".PHP_EOL;
}
public static function AC() {
echo "HELLOSTATIC".PHP_EOL;
}
}

$prefix='PRE';
$class='A';
$method='B';
$static='C';

$classVar=$prefix.$class;

(new $classVar())->{$class.$method}();
($prefix.$class)::{$class.$static}();

call_user_func(array(new $classVar(), $class.$method));
call_user_func($prefix.$class.'::'.$class.$static);

And for the rest. Yes, there is another way of doing it, but is that really enough for deprecating something?

Setting var type (can use variable casting nowadays):

Yes, we can cast, but is this reason for make someone to go through all the old code and do
-$var = intval($var);
+$var = (int) $var;

5 years ago by Arvids Godjuks — view source

unread

ср, 23 янв. 2019 г. в 12:04, Jani Ollikainen jani.ollikainen@valve.fi:

Hi,

The arguments why to deprecate didn't seem much more than, this maybe
could be deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?

But some comments that I didn't notice in others.

php_uname (use PHP_OS constant)

PHP_OS is php_uname('s'), how about rest:

mode
mode is a single character that defines what information is returned:

    'a': This is the default. Contains all modes in the sequence "s n
r v m".
's': Operating system name. eg. FreeBSD.
'n': Host name. eg. localhost.example.com.
'r': Release name. eg. 5.1.2-RELEASE.
'v': Version information. Varies a lot between operating systems.
'm': Machine type. eg. i386.

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the
same
class must not be used)

Both these have $allow_string

Function handling functions:

call_user_func (invoke directly)

Yes, they give a little performance hit, but I still kind of like them.
Like if we think the following, I think I would prefer call_user_func for
syntax.

class PREA {
public function AB() {
echo "HELLO".PHP_EOL;
}
public static function AC() {
echo "HELLOSTATIC".PHP_EOL;
}
}

$prefix='PRE';
$class='A';
$method='B';
$static='C';

$classVar=$prefix.$class;

(new $classVar())->{$class.$method}();
($prefix.$class)::{$class.$static}();

call_user_func(array(new $classVar(), $class.$method));
call_user_func($prefix.$class.'::'.$class.$static);

And for the rest. Yes, there is another way of doing it, but is that
really enough for deprecating something?

Setting var type (can use variable casting nowadays):

Yes, we can cast, but is this reason for make someone to go through all
the old code and do
-$var = intval($var);
+$var = (int) $var;

Hello to everyone.

As a userland dev, I have to agree with Jani here - when I looked through
the list of functions I had question marks all over the place about the
call_user_func* family. Sure, closures are nice, but as demonstrated
above they are not always the best-looking code and call_user_func*
family has it's used. Maybe I'm just not using this functionality that
much, so it seems like it's out of nowhere to deprecate/remove these for me.

is_writeable vs is_writable - the more you know music :)

--
Arvīds Godjuks

+371 26 851 664
arvids.godjuks@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

5 years ago by Girgias — view source

unread

Hi,
- phpversion (use `PHP_VERSION` constant)
The function takes an optional argument string $extension, what is the
replacement for that?

Didn 't realise not all of the extensions have a version constant.

- intval (for arbitrary base change there exists the math function
base_convert)
I've seen and myself use the following construct a lot to "quickly"
convert data within an array:

$data = array_map('intval', $data);

It's really practical because I don't have to write a (more verbose)
closure.

I'd argue this applies to the other *val calls too.

Seems like this is one of the only practical usages but a quite important
one
that I did not consider.

- join (alias of implode)
Old signatures:
- implode (historical signature)
Is there a correlation here why you mention the alias join and the
actual function implode? I hope you would want to leave either in the
language :-)

Completly unrelated, join is an alias whereas the old implode signature I'm
talking about is the implode(array $pieces, string $glue = '') which is not
recommended
compared to the recommended signature implode(string $glue, array $pieces)
which
mimics the explode signature.
I do want to keep implode() just deprecate the historical signature.

settype

AFAICS, there is no easy replacement for settype(). If the second argument
is a string literal, you can use type coercion + assignment at the price of
duplicating the occurrence of the first argument. If the second argument is
not known at compile time, you have to resort to a switch statement or
something similar.

I did not consider that someone might want to set the type of a variable at
runtime because
I can not see any pratical usages for that, imho you change a variable type
into another one
because you want to work with that specific type. But it basically boils
down to the same issue
as with gettype that without it you need to do a switch statement to get
something similar.

deprecate array function creation (array())

Here, I was really wondering why you didn’t mention function-like
destructuring as well (list()). (Not that I think it is a good idea.)

Thanks for catching that oversight, been a while since I haven't used list()
And I can totally see why you wouldn't think it's a good idea I just feel a
major version change
is an approriate time to bring such controversial issues to the table.

On Wed, 23 Jan 2019 at 11:04, Jani Ollikainen jani.ollikainen@valve.fi
wrote:

Hi,

The arguments why to deprecate didn't seem much more than, this maybe
could be deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?

My reasonning for theses deprecation is to get rid of some of the "clutter"
within the
PHP core, as in I don't see the benefit of having multiple aliases nor
functions which can
be achieved with some more modern constructs.

But some comments that I didn't notice in others.

php_uname (use PHP_OS constant)

PHP_OS is php_uname('s'), how about rest:

mode
mode is a single character that defines what information is returned:

    'a': This is the default. Contains all modes in the sequence "s n
r v m".
's': Operating system name. eg. FreeBSD.
'n': Host name. eg. localhost.example.com.

gethostname() can retrive this information

    'r': Release name. eg. 5.1.2-RELEASE.

PHP_EXTRA_VERSION

    'v': Version information. Varies a lot between operating systems.
    'm': Machine type. eg. i386.

For these two doesn't seem like I can find something equivalent

Classes/Objects functions:

is_a (use instanceof operator)

intanceof accepts a string as secodn operand but it needs to be within a
variable
however contrary to is_subclass_of, is_a does not accept a string as first
parameter
which makes is_a completly unnecessary imho.
See: https://3v4l.org/hn1Ao

is_subclass_of (not exactly what it's purpose is but the instanceof

operator SHOULD be a valid equivalence with another condition if the
same
class must not be used)

I do acknoledge this one has a usage as per one of my previous replies.

Function handling functions:

call_user_func (invoke directly)

Yes, they give a little performance hit, but I still kind of like them.
Like if we think the following, I think I would prefer call_user_func for
syntax.

class PREA {
public function AB() {
echo "HELLO".PHP_EOL;
}
public static function AC() {
echo "HELLOSTATIC".PHP_EOL;
}
}

$prefix='PRE';
$class='A';
$method='B';
$static='C';

$classVar=$prefix.$class;

(new $classVar())->{$class.$method}();
($prefix.$class)::{$class.$static}();

call_user_func(array(new $classVar(), $class.$method));
call_user_func($prefix.$class.'::'.$class.$static);

Going from the fact that you are using call_user_func instead of
forward_static_call
to make a static call I feel this shows how call_user_func can be abused
comapred to
just doing a direct call.
But in the end this maybe boils down to personal preferences as I find
call_user_fun
horrendous as a construction

And for the rest. Yes, there is another way of doing it, but is that
really enough for deprecating something?

Setting var type (can use variable casting nowadays):

Yes, we can cast, but is this reason for make someone to go through all
the old code and do
-$var = intval($var);
+$var = (int) $var;

I feel with a whole major version to be able to adapt that seems like a
reseonable drawback to
have - imho - better code.

On Wed, 23 Jan 2019 at 11:15, Arvids Godjuks arvids.godjuks@gmail.com
wrote:

Hello to everyone.

As a userland dev, I have to agree with Jani here - when I looked through
the list of functions I had question marks all over the place about the
call_user_func* family. Sure, closures are nice, but as demonstrated
above they are not always the best-looking code and call_user_func*
family has it's used. Maybe I'm just not using this functionality that
much, so it seems like it's out of nowhere to deprecate/remove these for me.

I feel like not a lot of people are aware that you can replace
call_user_func with the splat operator,
and as said just before imho closures are nicer than call_user_fun*

I just want to finish and say that thanks for the constructive feedback and
different opinions that
you all provided.

Best regards

George P. Banyard

5 years ago by Claude Pache — view source

unread

Le 23 janv. 2019 à 14:19, Girgias george.banyard@gmail.com a écrit :

settype

AFAICS, there is no easy replacement for settype(). If the second argument
is a string literal, you can use type coercion + assignment at the price of
duplicating the occurrence of the first argument. If the second argument is
not known at compile time, you have to resort to a switch statement or
something similar.

I did not consider that someone might want to set the type of a variable at
runtime because
I can not see any pratical usages for that, imho you change a variable type
into another one
because you want to work with that specific type. But it basically boils
down to the same issue
as with gettype that without it you need to do a switch statement to get
something similar.

So, since you didn’t see, here are some practical usages of settype():

<?php
function foo($bar) {
// $bar is supposed to be either a string, or a list of strings
settype($bar, 'array');
// ...
}

function qux($id) {
if (!(is_int($id) || is_string($id) && ctype_digit($id)))
throw new \TypeError;
settype($id, 'int');
// ...
}

class Foo implements SeekableIterator {
function seek(/* int */ $position): void {
// NOTE: we cannot use int typehint here, because PHP7.1 requires mixed
settype($position, 'int');
// ...
}
}
?>

Here are a usage of settype() with a non-constant second parameter: Define a utility function that cast a value to a given type when it is not null:

<?php
function cast_opt($val, $type) {
if ($val !== null)
settype($val, $type);
return $val;
}

$foo = cast_opt($bar, 'int') // equivalent to: $foo = $bar === null ? null : (int) $bar;
?>

Sure, one can avoid settype() and do it the complicated way, but why? What is the issue with settype(), so that you want to deprecate it?

—Claude

5 years ago by Girgias — view source

unread

So, since you didn’t see, here are some practical usages of settype():

<?php
function foo($bar) {
// $bar is supposed to be either a string, or a list of strings
settype($bar, 'array');
// ...
}

function qux($id) {
if (!(is_int($id) || is_string($id) && ctype_digit($id)))
throw new \TypeError;
settype($id, 'int');
// ...
}

class Foo implements SeekableIterator {
function seek(/* int */ $position): void {
// NOTE: we cannot use int typehint here, because PHP7.1 requires
mixed
settype($position, 'int');
// ...
}
}
?>

All these examples could very well use a typecast and or one of the *val
functions

Here are a usage of settype() with a non-constant second parameter: Define
a utility function that cast a value to a given type when it is not null:

<?php
function cast_opt($val, $type) {
if ($val !== null)
settype($val, $type);
return $val;
}

$foo = cast_opt($bar, 'int') // equivalent to: $foo = $bar === null ? null
: (int) $bar;
?>

Sure, one can avoid settype() and do it the complicated way, but why? What
is the issue with settype(), so that you want to deprecate it?

You didn't necessarely need to specify an example with a non-constant
second parameter
because you already gave valid arguments as why not to deprecate it, just
that I didn't see
them. I do appreciate the example however.

Why I wanted to deprecate is because I personally didn't see any usage
before,
you provided a valid usage and I don't see the point of deprecating it
anymore.
Maybe that wasn't clear from my previous reply. Because indeed removing
settype
brings back the same issue that I raised with gettype.
As it currently stands the only way I can see how settype can possibly be
deprecated
is ih PHP introduces a ReflectionVar classe which, like said in my initial
email, seems
like total overkill when a simple function exists.

Hope this clears everything up

Best regards

George P. Banyard

5 years ago by Dan Ackroyd — view source

unread

a list of functions which seem reasonable to deprecate

Classes/Objects functions:

is_a (use instanceof operator)

This is a fundamentally bad idea.

Functions can be passed around as functions, operators cannot be,
which makes it easier to composite functionality together with
functions than with operators.

The main reason to use operators at all is to improve readability.
i.e. $x = $y + 2; is easier to scan-read than $x = plus($y, 2);
(and I'm not sure the instanceof operator actually achieves this aim.)
but for when you want to be able to pass a function as a parameter,
then functions are much more powerful.

The same is true for floatval, intval etc.

Function handling functions:

call_user_func (invoke directly)

call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6

forward_static_call (same reason as call_user_func)

forward_static_cal_array (same reason as call_user_func_array)

func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))

func_get_args (same reason as func_get_arg)

func_num_args (same reason as func_get_arg)

Please no.

You're trying to set your preferred way of doing things as the only
way of doing things. I strongly prefer to use the call_user_func
versions and particularly call_user_func_array as they are clearer
(imo) but also they are easier for people to search online for what
they are doing.

btw this RFC https://wiki.php.net/rfc/consistent_callables probably
needs to be worked on before all the different ways of calling
'callables' is interchangeable anyway.

Filesystem aliases:

is_writeable — Alias of is_writable

Shouldn't we stick with the one that is spelt correctly. /s

Jani wrote:

The arguments why to deprecate didn't seem much more than, this maybe could be
deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?

Seconded.

Removing stuff that is working needs to have some justification, such
as removing ongoing maintenance or it's actively harmful, rather than
just we 'can' remove this.

cheers
Dan
Ack

5 years ago by Levi Morrison — view source

unread

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:

PHP Info/Option functions:

php_sapi_name (use PHP_SAPI constant)

phpversion (use PHP_VERSION constant)

php_uname (use PHP_OS constant)

Classes/Objects functions:

is_a (use instanceof operator)

is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)

Function handling functions:

call_user_func (invoke directly)

call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6

forward_static_call (same reason as call_user_func)

forward_static_cal_array (same reason as call_user_func_array)

func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))

func_get_args (same reason as func_get_arg)

func_num_args (same reason as func_get_arg)

Variable handling functions:
Aliases:

is_double

is_integer

is_long

is_real (already in the deprecation draft for PHP 7.4)

Setting var type (can use variable casting nowadays):

boolval

doubleval

floatval

intval (for arbitrary base change there exists the math function
base_convert)

settype

strval

gettype (more on this later [1])

String functions aliases:

chop (alias of rtrim)

join (alias of implode)

strchr (alias of strstr)

Maths functions aliases:

getrandmax

rand (use mt_rand instead)

srand (alias of mt_srand as of PHP 7.1)

Filesystem aliases:

diskfreespace — Alias of disk_free_space

fputs — Alias of fwrite

is_writeable — Alias of is_writable

set_file_buffer — Alias of stream_set_write_buffer

Old signatures:

implode (historical signature)

Controversial idea:

deprecate array function creation (array())

[1] About gettype:
The gettype function is really convenient as it can easily provide the type
of a variable without
needed to use a bunch of conditional checks, it can even as of PHP 7.2
signal if a resource
has been closed.
However, it still returns "double" for a float due to historical reasons
and it seems quite
complicated to change how it operates currently.
I have thought of two possible ideas which would allow PHP to return float
instead of double:

First, create a new reflection class ReflectionVar:
This feels even to me like a bit of an overkill more so that something
simple (a unique function
call) would require an object instantiation. But it can allow some
extensions such as the
Reflection for Reference RFC proposed by nikic (c.f.
https://wiki.php.net/rfc/reference_reflection)

Second, create a new function get_var_type($mixed):
This would behave exactly the same as the current implementation with the
one difference that
it would return 'float' instead of 'double'. This new function name would
be more consistent with how the other functions are named (namely
get_resource_type).
This implementation has the benefit of keeping it simple but will probably
duplicate code within the engine.

Just to remind these are only ideas and feedback is wholeheartedly
welcomed. I also probably
missed some more functions which could be deprecated as of PHP 8 but I feel
this covers
already a large portion.

Best regards

George P. Banyard

I see no reason to get rid of aliases, which comprises most of your list.

5 years ago by Thomas Hruska — view source

unread

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:

I've run a set of searches against GitHub code repos.

The numbers below are just generic metrics of usage and reloading search
result pages caused result counts to vary extremely widely. I didn't
look too in-depth at each result set beyond getting a number and a
general feel.

PHP Info/Option functions:
- php_sapi_name (use `PHP_SAPI` constant)

https://github.com/search?l=PHP&o=desc&q=php_sapi_name&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=PHP_SAPI&s=indexed&type=Code

1.02 million vs. 2.0 million code references. Both in active use.

- phpversion (use `PHP_VERSION` constant)

https://github.com/search?l=PHP&o=desc&q=phpversion&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=PHP_VERSION&s=indexed&type=Code

2.78 million vs. 5.1 million* code references.

Unfortunately, WordPress uses a variable called $php_version, which
throws off the global count.

WordPress itself uses phpversion(). That's 30% of all websites.

- php_uname (use `PHP_OS` constant)

No. PHP_OS only covers one option that php_uname() exposes. Simple
searches are turning up plenty of other php_uname() options in use.

Classes/Objects functions:
- is_a (use instanceof operator)

https://github.com/search?l=PHP&o=desc&q=is_a&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=instanceof&s=indexed&type=Code

1.7 million vs. 28.4 million results.

is_a() is still seeing some use but most people are using instanceof.

Also, $allow_string describes "This also prevents from calling
autoloader if the class doesn't exist." No equivalent functionality
exists without this function.

- is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)

https://github.com/search?l=PHP&o=desc&q=is_subclass_of&s=indexed&type=Code

1.54 million results.

In addition to the notes above about is_a(), CodeIgniter appears to use
this function.

Function handling functions:
- call_user_func (invoke directly)

https://github.com/search?l=PHP&o=desc&q=call_user_func&s=indexed&type=Code

10 million results. Broad, active usage.

Also, there are scenarios where you can't always invoke directly as you
claim. Been there, done that myself.

- call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6

https://github.com/search?l=PHP&o=desc&q=call_user_func_array&s=indexed&type=Code

11.4 million results (and breaks GitHub search for me in a unique way
I've not seen before). Broad, active usage.

See above.

- forward_static_call (same reason as call_user_func)

https://github.com/search?l=PHP&o=desc&q=forward_static_call&s=indexed&type=Code

52,200 results.

Can probably be deprecated.

- forward_static_call_array (same reason as call_user_func_array)

https://github.com/search?l=PHP&o=desc&q=forward_static_call_array&s=indexed&type=Code

14,581 results.

Can probably be deprecated.

- func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))

https://github.com/search?l=PHP&o=desc&q=func_get_arg&s=indexed&type=Code

1.1 million results.

While I personally never saw the point of this function since
func_get_args() exists, func_get_arg() sees regular use.

- func_get_args (same reason as func_get_arg)

https://github.com/search?l=PHP&o=desc&q=func_get_args&s=indexed&type=Code

9.2 million results.

Oh, and the first search result that turned up for me looks fun:

https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8c74110b72f44d564c7/src/GraphJS/Router.php

     self::initSession(...\func_get_args());

An elegant (and yet slightly horrifying) one-liner crushes whatever
argument you seemed to have about the splat operator: The author used both.

- func_num_args (same reason as func_get_arg)

https://github.com/search?l=PHP&o=desc&q=func_num_args&s=indexed&type=Code

3.35 million results.

Variable handling functions:
Aliases:
- is_double

https://github.com/search?l=PHP&o=desc&q=is_double&s=indexed&type=Code

345,700 results. Seems to be used for unit testing code bits verifying
return types.

- is_integer

https://github.com/search?l=PHP&o=desc&q=is_integer&s=indexed&type=Code

1 million results.

- is_long

https://github.com/search?l=PHP&o=desc&q=is_long&s=indexed&type=Code

95,400 results.

- is_real (already in the deprecation draft for PHP 7.4)

https://github.com/search?l=PHP&o=desc&q=is_real&s=indexed&type=Code

54,364 results. But not even the first page of results for me shows a
single call to it. Can be deprecated.

Setting var type (can use variable casting nowadays):
- boolval

https://github.com/search?l=PHP&o=desc&q=boolval&s=indexed&type=Code

54,400 results.

- doubleval

https://github.com/search?l=PHP&o=desc&q=doubleval&s=indexed&type=Code

214,200 results.

- floatval

https://github.com/search?l=PHP&o=desc&q=floatval&s=indexed&type=Code

1.7 million results.

- intval (for arbitrary base change there exists the math function
base_convert)

https://github.com/search?l=PHP&o=desc&q=intval&s=indexed&type=Code

13.65 million results.

- strval

https://github.com/search?l=PHP&o=desc&q=strval&s=indexed&type=Code

2.4 million results.

I'm not in favor of removal of these functions. While I don't use
them, lots of people still use them in conjunction with array_map() and
similar callback-oriented functions. I'd rather see them be optimized
within specific contexts such as array_map() for significantly improved
performance first before recommending deprecation.

- settype

https://github.com/search?l=PHP&o=desc&q=settype&s=indexed&type=Code

4.1 million results. However, most results seem to be classes with a
method called setType(), so those throw off an accurate global count.

There is an interesting usage here:

https://github.com/isaiassm/treinaweb-laravel-blade/blob/576448cd6a061b42c4742f490e2d771b5bd127b2/vendor/phpunit/phpunit/src/Util/Xml.php

 \settype($variable, $element->tagName);

Which I assume is for something like deserialization from XML.

- gettype (more on this later [1])

https://github.com/search?l=PHP&o=desc&q=gettype&s=indexed&type=Code

9.3 million results. However, most results seem to be classes with a
method called getType(), so those again throw off an accurate global count.

String functions aliases:
- chop (alias of rtrim)

https://github.com/search?l=PHP&o=desc&q=chop&s=indexed&type=Code

562,200 results. Mostly comments about chopping up strings using
substr(). Found a few legitimate usages such as Parsedown.

- join (alias of implode)

Impossible to determine. JOIN in SQL is severely skewing results.

- strchr (alias of strstr)

https://github.com/search?l=PHP&o=desc&q=strchr&s=indexed&type=Code

104,600 results.

Maths functions aliases:
- getrandmax

Shouldn't that have a comment like "(use mt_getrandmax() instead)"?

- rand (use mt_rand instead)
- srand (alias of mt_srand as of PHP 7.1)

Most usages from searches seem to be using the mt_...() functions
already anyway.

Filesystem aliases:

- diskfreespace — Alias of disk_free_space

https://github.com/search?l=PHP&o=desc&q=diskfreespace&s=indexed&type=Code

17,400 results. Can probably be deprecated.

- fputs —  Alias of fwrite

https://github.com/search?l=PHP&o=desc&q=fputs&s=indexed&type=Code

1.2 million results. Seems to be in active use.

- is_writeable — Alias of is_writable

https://github.com/search?l=PHP&o=desc&q=is_writeable&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=is_writable&s=indexed&type=Code

629,500 vs. 3.65 million results.

(On Google: 1.19 million vs. 6.2 million results for the words
writeable vs. writable.)

Deprecating this alias seems petty. Users currently don't have to look
up the function at the moment. Removing the alias will cause EVERYONE
to look up the function to be sure they remember how to correctly spell
it to avoid the deprecation warning.

- set_file_buffer — Alias of stream_set_write_buffer

https://github.com/search?l=PHP&o=desc&q=set_file_buffer&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=stream_set_write_buffer&s=indexed&type=Code

15,700 vs. 61,100 results.

Of the 15,700 results, I see only a couple of function usages in the
first few pages of results. Can probably be deprecated.

Old signatures:

- implode (historical signature)

Impossible to run a search for this.

Controversial idea:

- deprecate array function creation (array())

https://github.com/search?l=PHP&o=desc&q=array&s=indexed&type=Code

71.1 million results.

No.

Also, array() is not a function. It's a keyword with performance on-par
with [].

http://php.net/manual/en/reserved.keywords.php

I also prefer array() over []. It's more readable because it uses a
word rather than unsearchable symbols to define a structure.

Also, I get that arrays not actually implemented as such behind the
scenes but you simply can't deprecate an estimated 70 million lines of
code globally (and that's the code you can see, not including internal
software everywhere). "Hi, for PHP 8, we are going to fill your hard
drives via your application logs with deprecation warnings and crash
your servers. Have fun sorting that mess out!"

Finally, barring a serious security vulnerability, keywords should be
viewed as permanent fixtures of the language. They can't be deprecated.
That's why there are so few keywords. Far too much userland code will
unnecessarily break. You suggest deprecating 'array' but not
'enddeclare', 'endfor', 'endforeach', 'endif', 'endswitch', 'endwhile'.
All of those have alternative "shortcuts" but you didn't mention
deprecating those keywords even though there is far less usage compared
to 'array'.

Just to remind these are only ideas and feedback is wholeheartedly
welcomed. I also probably
missed some more functions which could be deprecated as of PHP 8 but I feel
this covers
already a large portion.

Best regards

George P. Banyard

--
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/

And once you find my software useful:

http://cubiclesoft.com/donate/

5 years ago by Tom Worster — view source

unread

Hi George,

Iiuc, the problem you're trying to solve is that PHP offers too many
ways to do the same thing and if there were fewer then PHP code would be
easier to write, read and maintain.

Differences in code that make no difference to the compiler are
differences in style.

The conventional solution is to adopt a style spec and use a linter.
I've experienced this in Ruby, JS and PHP and it's effective.

This conventional solution causes a lot less breakage than attempting to
mitigate the problem by changing the language.

It's annoying enough to have to deal with the promulgation of a new
style spec and corresponding linter in your organization. Imagine if
such a change were to be promulgated by The Rulers of PHP.

Tom

5 years ago by Benjamin Morel — view source

unread

2.78 million vs. 5.1 million* code references.
1.54 million results.
10 million results. Broad, active usage.
...

I would not in any way base deprecation decisions on current usage
statistics. If there are several ways to do something, and one is clearly
better than the others (naming consistency) then the choice should IMHO be
imposed to the community.
Trying to make 10+ years old codebases work with recent versions of PHP
without modification slows down development a lot.
Major versions are here to break things. Changelogs and runtime deprecation
notices are here to help.

5 years ago by Rowan Collins — view source

unread

On Wed, 23 Jan 2019 at 16:37, Benjamin Morel benjamin.morel@gmail.com
wrote:

2.78 million vs. 5.1 million* code references.
1.54 million results.
10 million results. Broad, active usage.
...

I would not in any way base deprecation decisions on current usage
statistics. If there are several ways to do something, and one is clearly
better than the others (naming consistency) then the choice should IMHO be
imposed to the community.

Every time you impose a change on the community, you are costing that
community goodwill, time, and ultimately money. It is absolutely critical
that decisions weigh that cost against the expected benefit.

If the expected benefit is a small increase in readability, and the
expected cost is a huge volume of existing code requiring changes, we
should rule out the change.

Trying to make 10+ years old codebases work with recent versions of PHP
without modification slows down development a lot.
Major versions are here to break things.

No, major versions are here to improve the language while breaking as
little as possible. We are not in the business of change for change's
sake; every change needs to be justified, regardless of where in the
release cycle it comes.

Changelogs and runtime deprecation notices are here to help.

As others have pointed out, runtime deprecation notices have a cost on
their own - they create noise in logs, obscuring more important changes,
and taking up disk space. Again, this is a cost that needs to be weighed
against the expected benefit.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Girgias — view source

unread

a list of functions which seem reasonable to deprecate

Classes/Objects functions:

is_a (use instanceof operator)

This is a fundamentally bad idea.

Functions can be passed around as functions, operators cannot be,
which makes it easier to composite functionality together with
functions than with operators.

The main reason to use operators at all is to improve readability.
i.e. $x = $y + 2; is easier to scan-read than $x = plus($y, 2);
(and I'm not sure the instanceof operator actually achieves this aim.)
but for when you want to be able to pass a function as a parameter,
then functions are much more powerful.

The same is true for floatval, intval etc.

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

Function handling functions:

call_user_func (invoke directly)

call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6

forward_static_call (same reason as call_user_func)

forward_static_cal_array (same reason as call_user_func_array)

func_get_arg (seems unnecessary as of PHP 5.6 with variadic
functions
(splat operator))

func_get_args (same reason as func_get_arg)

func_num_args (same reason as func_get_arg)

btw this RFC https://wiki.php.net/rfc/consistent_callables probably
needs to be worked on before all the different ways of calling
'callables' is interchangeable anyway.

Now that's a compelling reason where I can get behind not doing so.

I've run a set of searches against GitHub code repos.

The numbers below are just generic metrics of usage and reloading search
result pages caused result counts to vary extremely widely. I didn't
look too in-depth at each result set beyond getting a number and a
general feel.

Cheers for doing this Thomas.

- func_get_args (same reason as func_get_arg)
https://github.com/search?l=PHP&o=desc&q=func_get_args&s=indexed&type=Code

9.2 million results.

Oh, and the first search result that turned up for me looks fun:

https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8c74110b72f44d564c7/src/GraphJS/Router.php
     self::initSession(...\func_get_args());
An elegant (and yet slightly horrifying) one-liner crushes whatever
argument you seemed to have about the splat operator: The author used
both.

Now this is an unexpected result on which I'll see myself beaten.

I'm not in favor of removal of these functions. While I don't use

them, lots of people still use them in conjunction with array_map() and
similar callback-oriented functions. I'd rather see them be optimized
within specific contexts such as array_map() for significantly improved
performance first before recommending deprecation.

It has more or less already been established that deprecating those
function is pretty
much impossible in the current state.

- gettype (more on this later [1])
https://github.com/search?l=PHP&o=desc&q=gettype&s=indexed&type=Code

9.3 million results. However, most results seem to be classes with a
method called getType(), so those again throw off an accurate global count.

I remember encountering this issue while I was first writting this email a
month ago and couldn't
get meaningfull results.

Maths functions aliases:
- getrandmax
Shouldn't that have a comment like "(use mt_getrandmax() instead)"?

It should,

- rand (use mt_rand instead)
- srand (alias of mt_srand as of PHP 7.1)
Most usages from searches seem to be using the mt_...() functions
already anyway.

Good to know

- is_writeable — Alias of is_writable
https://github.com/search?l=PHP&o=desc&q=is_writeable&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=is_writable&s=indexed&type=Code

629,500 vs. 3.65 million results.

(On Google: 1.19 million vs. 6.2 million results for the words
writeable vs. writable.)

Deprecating this alias seems petty. Users currently don't have to look
up the function at the moment. Removing the alias will cause EVERYONE
to look up the function to be sure they remember how to correctly spell
it to avoid the deprecation warning.

It may same petty but it was just an idea.
Seems like it's to big of a hassle to convert.

Old signatures:
- implode (historical signature)
Impossible to run a search for this.

Understandable that this is impossible to search for.

Controversial idea:
- deprecate array function creation (array())
https://github.com/search?l=PHP&o=desc&q=array&s=indexed&type=Code

71.1 million results.

No.

Also, array() is not a function. It's a keyword with performance on-par
with [].

http://php.net/manual/en/reserved.keywords.php

I also prefer array() over []. It's more readable because it uses a
word rather than unsearchable symbols to define a structure.

Also, I get that arrays not actually implemented as such behind the
scenes but you simply can't deprecate an estimated 70 million lines of
code globally (and that's the code you can see, not including internal
software everywhere). "Hi, for PHP 8, we are going to fill your hard
drives via your application logs with deprecation warnings and crash
your servers. Have fun sorting that mess out!"

Finally, barring a serious security vulnerability, keywords should be
viewed as permanent fixtures of the language. They can't be deprecated.
That's why there are so few keywords. Far too much userland code will
unnecessarily break. You suggest deprecating 'array' but not
'enddeclare', 'endfor', 'endforeach', 'endif', 'endswitch', 'endwhile'.
All of those have alternative "shortcuts" but you didn't mention
deprecating those keywords even though there is far less usage compared
to 'array'.

In all honnesty, those keywords didn't even cross my mind because I have
so rarely seen them.
Now if people want to discuss if those should be deprecated or not I'm all
for it
But from the general vibe I get this seems like it is not going to go
anywhere.

Best regards

George P. Banyard

5 years ago by Rowan Collins — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
Seems like the kind of thing either of them might work on...) to add a
syntax for using any operator as a callable. I don't think it got beyond a
thought experiment, but it's an interesting concept, and would
theoretically remove the need for some of this duplicate functionality.

Regards,

Rowan Collins
[IMSoP]

5 years ago by Girgias — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
Seems like the kind of thing either of them might work on...) to add a
syntax for using any operator as a callable. I don't think it got beyond a
thought experiment, but it's an interesting concept, and would
theoretically remove the need for some of this duplicate functionality.

Indeed seems like Andrea Faulds did publish an RFC which is in the
Under discussion section: https://wiki.php.net/rfc/operator_functions

Best regards

George P. Banyard

5 years ago by Christoph M. Becker — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
Seems like the kind of thing either of them might work on...) to add a
syntax for using any operator as a callable. I don't think it got beyond a
thought experiment, but it's an interesting concept, and would
theoretically remove the need for some of this duplicate functionality.

See https://wiki.php.net/rfc/operator_functions (which is still “under
discussion”, by the way).

--
Christoph M. Becker

5 years ago by Dan Ackroyd — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

No, but only I'd much strongly prefer we have some syntax for defined
'short closures' ala Javascript:

$values = [1, 2, 3];
$bar = array_map($x => $x + 1, $values);

// $values === [2, 3, 4];

as those cover much more than the basic arithmetic operations, are
nice and readable after you've used them a few times.

cheers
Dan
Ack

5 years ago by Girgias — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

No, but only I'd much strongly prefer we have some syntax for defined
'short closures' ala Javascript:

$values = [1, 2, 3];
$bar = array_map($x => $x + 1, $values);

// $values === [2, 3, 4];

as those cover much more than the basic arithmetic operations, are
nice and readable after you've used them a few times.

cheers
Dan
Ack

I didn't even know you could omit parenthesis in JS closures, the more you
know.
But it seems like there is already a Draft for an RFC for short closures in
PHP but
that one seems to have come to a halt.

I've realised I didn't go through array functions so just gonna bring them
up for the sake of not creating a new thread:

key_exist - alias of array_key_exist
A GitHub search brings up 276 078 results where there are some userland
usage but also a whole lot of unit tests usage
https://github.com/search?l=PHP&p=1&q=key_exists&type=Code
pos - alias for current
Can't seem to get any meaningful result by searching on GitHub as it
picks up more or less anything which contains pos
https://github.com/search?l=PHP&q=pos%28&type=Code
sizeof - alias of count
A Github search brings up 1 617 789 results with lots of userland usage
but also a bit of unit testing
https://github.com/search?l=PHP&p=1&q=sizeof&type=Code

And then there is array_multisort a function which has a signature which
isn't even possible in userland code.
(https://secure.php.net/manual/en/function.array-multisort.php).
Other than the fact that this function's documentation isn't totally
correct in my opinion I did a Github search to see if people use it.
From what I've seen in the search results [1], around 620k, it is only used
in phpt unit tests and a unit test of a parser.

Now, I don't think a function which doesn't follow normal function
signature converntion (or isn't even possible) shouldn't really be part of
the language.
Moreso that it seems barely anybody uses it.
What's people opinion on deprecating array_multisort ?

[1]
https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code

George P. Banyard

5 years ago by Claude Pache — view source

unread

And then there is array_multisort a function which has a signature which
isn't even possible in userland code.
(https://secure.php.net/manual/en/function.array-multisort.php https://secure.php.net/manual/en/function.array-multisort.php).
Other than the fact that this function's documentation isn't totally
correct in my opinion I did a Github search to see if people use it.
From what I've seen in the search results [1], around 620k, it is only used
in phpt unit tests and a unit test of a parser.

[1]
https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code

Presumably, if you sort the results by ”Best match”, test units appear first because they are the only occasions where you invoke this function ten times in a row. Try to sort by ”Recently indexed” and you’ll get some real usages.

Now, I don't think a function which doesn't follow normal function
signature converntion (or isn't even possible) shouldn't really be part of
the language.
Moreso that it seems barely anybody uses it.
What's people opinion on deprecating array_multisort ?

One of the most important things to consider when proposing deprecations is the migration cost you impose to your users. It is apparently something easily forgotten by those that love deprecations : “In order to make migrating your legacy code even more painful, we have carefully chosen to deprecate a function that you’ll have trouble to reimplement userland.”

Moreover, even when assuming (incorrectly) that it is barely used: What is the benefit of deprecating array_multisort? (This question is valid also for future deprecation proposals.)

—Claude

5 years ago by Stephen Reay — view source

unread

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?

No, but only I'd much strongly prefer we have some syntax for defined
'short closures' ala Javascript:

$values = [1, 2, 3];
$bar = array_map($x => $x + 1, $values);

// $values === [2, 3, 4];

as those cover much more than the basic arithmetic operations, are
nice and readable after you've used them a few times.

cheers
Dan
Ack

I didn't even know you could omit parenthesis in JS closures, the more you
know.
But it seems like there is already a Draft for an RFC for short closures in
PHP but
that one seems to have come to a halt.

I've realised I didn't go through array functions so just gonna bring them
up for the sake of not creating a new thread:

key_exist - alias of array_key_exist
A GitHub search brings up 276 078 results where there are some userland
usage but also a whole lot of unit tests usage
https://github.com/search?l=PHP&p=1&q=key_exists&type=Code

pos - alias for current
Can't seem to get any meaningful result by searching on GitHub as it
picks up more or less anything which contains pos
https://github.com/search?l=PHP&q=pos%28&type=Code

sizeof - alias of count
A Github search brings up 1 617 789 results with lots of userland usage
but also a bit of unit testing
https://github.com/search?l=PHP&p=1&q=sizeof&type=Code

And then there is array_multisort a function which has a signature which
isn't even possible in userland code.
(https://secure.php.net/manual/en/function.array-multisort.php).
Other than the fact that this function's documentation isn't totally
correct in my opinion I did a Github search to see if people use it.

From what I've seen in the search results [1], around 620k, it is only used
in phpt unit tests and a unit test of a parser.

Now, I don't think a function which doesn't follow normal function
signature converntion (or isn't even possible) shouldn't really be part of
the language.
Moreso that it seems barely anybody uses it.
What's people opinion on deprecating array_multisort ?

[1]
https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code

George P. Banyard

My opinion on deprecating array_multisort is: don’t.

Plenty of provided functionality exists specifically because it’s stuff that’s not feasible or not efficient to do in userland.

Given the fairly unique capabilities of array_multisort, what is your suggested replacement for the half-million instances on GitHub alone (lets not forget that GitHub is not the single repository of all code ever written, and the search you’ve referenced is only public repos)?

If array_multisort is viable for deprecation, surely array_fill is as well? At least that one is replaceable with a simple userland implementation. What about array_rand? Or array_product - that has a paltry 31K results on GitHub. Or array_chunk, that’s only 2/3 as many results as for array_multisort.

Heck, why not remove all built in functions and just force everyone to write the entire runtime from scratch in userland code?

In case you didn’t realise, this is sarcasm at the extreme, because your given reasons to support deprecation are absurd.