On 12 October 2014 00:47, Andrea Faulds <a...@ajf.me> wrote:

>
> On 11 Oct 2014, at 23:42, Rowan Collins <rowan.coll...@gmail.com> 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.

Greets,

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Reply via email to