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_SAPIconstant) - phpversion (use
PHP_VERSIONconstant) - php_uname (use
PHP_OSconstant)
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
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_SAPIconstant)- phpversion (use
PHP_VERSIONconstant)- php_uname (use
PHP_OSconstant)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.
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
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/DkMC4George P. Banyard
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
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]
Hello,
Can we also add strange function names without any naming conventions to
this listIn 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
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]
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
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]
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]
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]
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]
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]
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]
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
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]
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
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]
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
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
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
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.netHello Yasuo Ohgaki.
By Deprecation, I was indeed meaning that as of PHP 8 these function
should throw
E_DEPRECATEDerrors 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
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.netHello Yasuo Ohgaki.
By Deprecation, I was indeed meaning that as of PHP 8 these function
should throw
E_DEPRECATEDerrors 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
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
- 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
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_OSconstant)
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;
ср, 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_OSconstant)
PHP_OSis 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 nr 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
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
*valcalls 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_OSconstant)
PHP_OSis 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 nr 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 andcall_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
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
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 withsettype(), 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
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
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_SAPIconstant)- phpversion (use
PHP_VERSIONconstant)- php_uname (use
PHP_OSconstant)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.
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:
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:
\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.
And once you find my software useful:
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