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

From: Date: Fri, 10 Oct 2014 20:27:59 +0000
Subject: Deprecation of func_get_args(), call_user_func_array() and related API
Groups: php.internals 
Request: Send a blank email to internals+get-77854@lists.php.net to get a copy of this message
Hello folks, 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. This makes debugging code quite complicated if not just annoying and frustrating. Additionally, it seems like call_user_func and similars are impacting performance in some parts of my codebase (event dispatcher logic). 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: - http://3v4l.org/HDQb6 (call_user_func) - http://3v4l.org/AgEG5 (call_user_func_array) - http://3v4l.org/O3G6T (func_get_args) (broken in HHVM) - http://3v4l.org/vcYso (func_get_arg) (broken in HHVM) - http://3v4l.org/cg8i0 (func_num_args) (broken in HHVM) Those files could moved to a library and included when running on legacy codebases. Eventually, grepping for those function calls is also trivial. Here's also the example with the exception and the userland implementation of call_user_func, which has a much more readable/clear/inspectable stack trace: http://3v4l.org/i4G8c Thoughts? If this idea gets enough traction, I'd gladly go and ask for karma, open an RFC and eventually provide a patch if I'm able to. Greets, Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/

« previous php.internals (#77854) next »