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/