On Mon, Oct 13, 2014 at 2:45 AM, Marco Pivetta <ocram...@gmail.com> wrote: > 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.
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
