On 13.10.2014 02:45, Marco Pivetta 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. 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/ > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
