Deprecation of func_get_args(), call_user_func_array() and related API

Assuming PHP 7.0 came out in 2 years from now, I don't expect a decent
adoption rate anyway for the next 5 years.

So you want to decrease adoption rate even more for a very small win?
Fantastic (irony!)

johannes

The point is removing more API from core and moving it to userland.
API implemented in core needs to be maintained by core devs, and is
non-transparent to consumers (reflection/debugging/etc).
In general, I've always been against any non-language feature that isn't
implemented with the language itself, but it's my point of view: as a
simple rule of thumb (my rule, many would just say I'm crazy), if it can be
implemented in PHP, then don't add it to core or extensions.

For adding features that is a good rule. For removing not. Even less
for a feature with more than a million hits on GitHub ...
https://github.com/search?l=php&q=func_get_args&type=Code&utf8=%E2%9C%93
(while that metric is bad - too many duplicates due to forks and from
phpt test suite, but still a notable number)

johannes

func_get_args() and func_num_args(), OTOH, existed solely to support
variadics, and anything taking advantage of them being functions rather
than a language structure would have to be quite exotic and arcane, so in
principle they could, eventually, be removed, but I agree with others that
it's far too soon to remove a feature which has been around since 4.0 just
becuase 5.6 includes a better alternative.

They have some (admittedly limited) use beyond variadics. If you make a
function and later make it redirect to another, you can preserve your
typehints by using func_get_args() rather than using the … syntax.

Can anyone come up with those use-cases? If there is something that
func_get_args() can do and that can't be done with the code examples that
I've pasted before, then I'm missing some bits of information that may make
the entire proposal moot.

If they're included in the core distribution, then why make them
optional at all? If it's just a question of how the functions behave, then
surely an included (and C-level) implementation should be sought which has
the better behaviour?

This matches my own thoughts. There is nothing wrong with these functions.
There are just some issues with their implementation. We do not need to get
rid of the functions, that would be an absurd overreaction. We should just
fix the implementations.

The point is removing more API from core and moving it to userland.
API implemented in core needs to be maintained by core devs, and is
non-transparent to consumers (reflection/debugging/etc).
In general, I've always been against any non-language feature that isn't
implemented with the language itself, but it's my point of view: as a
simple rule of thumb (my rule, many would just say I'm crazy), if it can be
implemented in PHP, then don't add it to core or extensions.
I would suggest the same deprecation approach for many array_* functions,
but I assume that I'd only start a giant shitstorm (pardon the wording, but
that's the most precise term for that) about performance.

Yep, rewriting array_ functions in PHP will hit a very huge VM
overhead and drop the function's performance dramatically.

For func_get_args() and call_user_func() , we could add a deprecation
notice to PHP7 to tell people there are "better" ways of doing this
now.

Julien.P

func_get_args() and func_num_args(), OTOH, existed solely to support
variadics, and anything taking advantage of them being functions rather
than a language structure would have to be quite exotic and arcane, so in
principle they could, eventually, be removed, but I agree with others that
it's far too soon to remove a feature which has been around since 4.0 just
becuase 5.6 includes a better alternative.

They have some (admittedly limited) use beyond variadics. If you make a
function and later make it redirect to another, you can preserve your
typehints by using func_get_args() rather than using the … syntax.
Can anyone come up with those use-cases? If there is something that
func_get_args() can do and that can't be done with the code examples that
I've pasted before, then I'm missing some bits of information that may make
the entire proposal moot.
Your implementation of "userland_call_user_func" doesn't have the same
visibility as "call_user_func[_array]":
http://3v4l.org/lNgub

If they're included in the core distribution, then why make them
optional at all? If it's just a question of how the functions behave, then
surely an included (and C-level) implementation should be sought which has
the better behaviour?

This matches my own thoughts. There is nothing wrong with these functions.
There are just some issues with their implementation. We do not need to get
rid of the functions, that would be an absurd overreaction. We should just
fix the implementations.

The point is removing more API from core and moving it to userland.
API implemented in core needs to be maintained by core devs, and is
non-transparent to consumers (reflection/debugging/etc).
In general, I've always been against any non-language feature that isn't
implemented with the language itself, but it's my point of view: as a
simple rule of thumb (my rule, many would just say I'm crazy), if it can be
implemented in PHP, then don't add it to core or extensions.
I would suggest the same deprecation approach for many array_* functions,
but I assume that I'd only start a giant shitstorm (pardon the wording, but
that's the most precise term for that) about performance.

Anyway, it's clear that this proposal has short legs, and won't get
anywhere in a vote.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

In general, I've always been against any non-language feature that
isn't implemented with the language itself, but it's my point of view:
as a simple rule of thumb (my rule, many would just say I'm crazy), if
it can be implemented in PHP, then don't add it to core or extensions.

I think there are a few different ideas here which are worth unpacking.

Firstly, no language I can think of has ever been distributed or
standardised without a standard library of functions. We all know that
the abstractions we use could be reimplemented using lower-level
structures, but knowing that an implementation is there "out of the box"
means we don't need to spend time reinventing the wheel, or learning the
subtleties of dozens of competing wheels. Along with syntax and a type
system, the standard library is a key part of a language's identity.

Secondly, there is the question of "engine magic". I am actually rather
sympathetic to the idea that userland code should be able to access
more of the features that extension code can. For instance, object
handlers written in C can implement many more hooks than userland
objects can through magic __* methods and SPL interfaces, even when it's
not the extension's purpose to manipulate the engine. I'd love it to be
possible to write a version of SimpleXML in PHP. That said, there are
some things which really do need a close integration with the engine to
function correctly; variadics support is useful, but it clearly doesn't
allow manipulation of the actual parameter passing logic in the way a
debug extension might, and nor should it.

That does not, however, mean that all code that can be written in PHP
should be written in PHP. High-level abstractions tend to come at a
cost to performance, so it makes sense that many parts of a language's
standard library are actually written in a lower-level language - in the
case of PHP, that means implementing things in C; in the case of C, it
might mean implementing them in assembly. Sometimes, too, it just makes
more sense to keep everything in one place, such as if an extension is
binding to an existing C library, but also provides some unique
functions of its own.

Finally, there is the question of bundling and maintenance. A function
distributed with core will have to be maintained by core developers
whatever language it is written in. I guess having a section of the
standard library written in PHP might attract more people to contribute
to its maintenance, although the likely complexity of such code would
probably still be intimidating to many. There's no reason that rewriting
it in a different language would automatically make it optional - or
that keeping it in C makes it automatically compulsory. PHP already has
a modular structure, which distinguishes between mandatory, bundled, and
externally maintained "extensions", so if we really wanted a "low fat"
PHP we could just make more parts optional.

None of this should be taken as argument that anything and everything
should remain in the core, but it does add up to a rather higher bar for
removals or exclusions than "it's possible to do it another way, so we
don't need to include this way".

--
Rowan Collins
[IMSoP]