On 12 October 2014 00:47, Andrea Faulds wrote:
On 11 Oct 2014, at 23:42, Rowan Collins wrote:

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.

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


Marco Pivetta



Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 14 of 29 | next ›
Discussion Overview
groupphp-internals @
postedOct 10, '14 at 8:28p
activeDec 1, '14 at 7:22a



site design / logo © 2019 Grokbase