Re: Deprecation of func_get_args(), call_user_func_array() and related API

On 10 October 2014 22:34, Andrea Faulds <ajf@ajf.me> wrote: > > On 10 Oct 2014, at 21:27, Marco Pivetta <ocramius@gmail.com> wrote: > > > While rambling with some code today, I realized that > > call_user_func > > behaves strangely, appearing and disappearing from stack traces depending > > on versions of PHP. For an example, compare > > http://3v4l.org/fGpIk#vphp7@20140901, > > http://3v4l.org/fGpIk#v530 and > > http://3v4l.org/fGpIk#vhhvm-301. > > IIRC this is a bug caused by PHP7 eliminating the call to the function > entirely, and instead inserting a normal function call opcode. See: > > https://github.com/php/php-src/blob/292421d3a1fcefe88c3017ffdb9f889c39a6c8c1/Zend/zend_compile.c#L2777 > > This could possibly be fixed somehow. > Having the stack trace entry there would be enough too. > > Additionally, it seems like call_user_func and similars > > are impacting > > performance in some parts of my codebase (event dispatcher logic). > > In PHP 7, due to the function call removal, it should be just the same, > performance-wise, as a normal function call. > Good to know! And I suppose no additional stack frame is created either? > > Therefore, here comes my idea of simply getting rid of > > call_user_func, > > call_user_func_array, > > func_get_args, func_num_args and > func_get_arg. > > > > My plan for it would be to add a deprecation (notice? not sure about > that) > > in PHP 5.7, and a complete removal of those methods in PHP 7.0. > > > > BC compatibility is easily achieved as variadics ( > > https://wiki.php.net/rfc/variadics) allow for writing > > cleaner and less > > complex versions: > > “Easily” achieved? No. This would break an awful, awful lot of existing > PHP code with no gain. There’s no need to deprecate it any time soon. The > variadics syntax is merely a nicer alternative. We should not force people > to rewrite existing code to use it. There is absolutely no need to get rid > of func_get_args. > > I would vote against any such proposal, and I hope others on the list > would join me in doing so. > I'd actually just deprecate any API for which there isn't a use-case anymore, but that's my own vision. As I've already demonstrated, a polyfill already exists and is easy to implement/use too. Exactly like what happened with register_globals (which is much harder to find), it would be a small addition at the beginning of <whatever-legacy-thing> you are using. Could you elaborate a bit on this? Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/