Everything

php

Home » Project » Newsgroups » php.internals » Deprecation ideas for PHP 8 »

Deprecation ideas for PHP 8

php.internals

Girgias

7 years ago

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

Stephen Reay

7 years ago

> On 23 Jan 2019, at 03:34, Girgias <george.banyard@gmail.com> wrote:
>
> 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.

Girgias

7 years ago

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

>
> > On 23 Jan 2019, at 03:34, Girgias <george.banyard@gmail.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

Midori Kocak

7 years ago

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 22:22, Girgias <george.banyard@gmail.com> wrote:

Yasuo Ohgaki

7 years ago

On Wed, Jan 23, 2019 at 6:28 AM Midori Koçak <mtkocak@gmail.com> wrote:

> 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

Rowan Collins

7 years ago

On 22/01/2019 21:27, Midori Koçak wrote:

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

Peter Kokot

7 years ago

Hello,

On Tue, 22 Jan 2019 at 23:40, Rowan Collins <rowan.collins@gmail.com> wrote:

>
> On 22/01/2019 21:27, Midori Koçak wrote:
> > 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

Rowan Collins

7 years ago

On 30/01/2019 17:28, Peter Kokot wrote:

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

Peter Kokot

7 years ago

On Wed, 30 Jan 2019 at 20:51, Rowan Collins <rowan.collins@gmail.com> wrote:

>
> On 30/01/2019 17:28, Peter Kokot wrote:
> > 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

Rowan Collins

7 years ago

On Thu, 31 Jan 2019 at 07:34, Peter Kokot <peterkokot@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]

Benjamin Morel

7 years ago

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:

Yasuo Ohgaki

7 years ago

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

> On Thu, 31 Jan 2019 at 07:34, Peter Kokot <peterkokot@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

Christoph Becker

7 years ago

On 31.01.2019 at 08:34, Peter Kokot wrote:

> 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

Yasuo Ohgaki

7 years ago

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

Girgias

7 years ago

On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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

Yasuo Ohgaki

7 years ago

On Wed, Jan 23, 2019 at 7:08 AM Girgias <george.banyard@gmail.com> wrote:

> On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
>> 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

Girgias

7 years ago

On Tue, 22 Jan 2019 at 23:28, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> On Wed, Jan 23, 2019 at 7:08 AM Girgias <george.banyard@gmail.com> wrote:
>
> > On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
> >
> >> 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

Markus Fischer

7 years ago

Hi,

On 22.01.19 21:34, Girgias wrote:

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

Claude Pache

7 years ago

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

Jani Ollikainen

7 years ago

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;

Arvids Godjuks

7 years ago

ср, 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

Girgias

7 years ago

On Wed, 23 Jan 2019 at 09:02, Markus Fischer <markus@fischer.name> wrote:

> Hi,
>
> On 22.01.19 21:34, Girgias wrote:
> >     - 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.

On Wed, 23 Jan 2019 at 09:19, Claude Pache <claude.pache@gmail.com> wrote:

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

Claude Pache

7 years ago

> Le 23 janv. 2019 à 14:19, Girgias <george.banyard@gmail.com> a écrit :
>
>
>
> On Wed, 23 Jan 2019 at 09:19, Claude Pache <claude.pache@gmail.com> wrote:
>
>>
>>>  - 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

Girgias

7 years ago

On Wed, 23 Jan 2019 at 15:43, Claude Pache <claude.pache@gmail.com> wrote:

> 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 want*ed* 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

Dan Ackroyd

7 years ago

On Tue, 22 Jan 2019 at 20:34, Girgias <george.banyard@gmail.com> wrote:

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

Levi Morrison

7 years ago

On Tue, Jan 22, 2019 at 1:35 PM Girgias <george.banyard@gmail.com> wrote:

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

Thomas Hruska

7 years ago

On 1/22/2019 1:34 PM, Girgias wrote:

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

Tom Worster

7 years ago

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