On Tue, 22 Jan 2019 at 20:34, Girgias <george.bany...@gmail.com> wrote: > > a list of functions which seem reasonable to deprecate
> Classes/Objects functions: > > - is_a (use instanceof operator) This is a fundamentally bad idea. Functions can be passed around as functions, operators cannot be, which makes it easier to composite functionality together with functions than with operators. The main reason to use operators at all is to improve readability. i.e. `$x = $y + 2;` is easier to scan-read than `$x = plus($y, 2);` (and I'm not sure the instanceof operator actually achieves this aim.) but for when you want to be able to pass a function as a parameter, then functions are much more powerful. The same is true for floatval, intval etc. > Function handling functions: > > - call_user_func (invoke directly) > - call_user_func_array (arguments can be provided with the splat > operator (...) as of PHP 5.6 > - forward_static_call (same reason as call_user_func) > - forward_static_cal_array (same reason as call_user_func_array) > - func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions > (splat operator)) > - func_get_args (same reason as func_get_arg) > - func_num_args (same reason as func_get_arg) Please no. You're trying to set your preferred way of doing things as the only way of doing things. I strongly prefer to use the call_user_func versions and particularly call_user_func_array as they are clearer (imo) but also they are easier for people to search online for what they are doing. btw this RFC https://wiki.php.net/rfc/consistent_callables probably needs to be worked on before all the different ways of calling 'callables' is interchangeable anyway. > Filesystem aliases: > - is_writeable — Alias of is_writable Shouldn't we stick with the one that is spelt correctly. /s Jani wrote: > The arguments why to deprecate didn't seem much more than, this maybe could be > deprecated. I think there should usually be some > benefits of deprecating, otherwise why not just leave it as it is? Seconded. Removing stuff that is working needs to have some justification, such as removing ongoing maintenance or it's actively harmful, rather than just we 'can' remove this. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
