On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd <dan...@basereality.com> wrote:
> 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. > I understand the rationale for functional programming, may I ask in your opinion should PHP have built-in functions for arithmetic operations so that it can be used in such a way without needing userland implementations? > > > 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) > > 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. > Now that's a compelling reason where I can get behind not doing so. On Wed, 23 Jan 2019 at 17:19, Thomas Hruska <thru...@cubiclesoft.com> wrote: > I've run a set of searches against GitHub code repos. > > The numbers below are just generic metrics of usage and reloading search > result pages caused result counts to vary extremely widely. I didn't > look too in-depth at each result set beyond getting a number and a > general feel. > > Cheers for doing this Thomas. > - func_get_args (same reason as func_get_arg) > > https://github.com/search?l=PHP&o=desc&q=func_get_args&s=indexed&type=Code > > 9.2 million results. > > Oh, and the first search result that turned up for me looks fun: > > > https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8c74110b72f44d564c7/src/GraphJS/Router.php > > self::initSession(...\func_get_args()); > > An elegant (and yet slightly horrifying) one-liner crushes whatever > argument you seemed to have about the splat operator: The author used > both. > Now this is an unexpected result on which I'll see myself beaten. I'm not in favor of removal of these functions. While *I* don't use > them, lots of people still use them in conjunction with array_map() and > similar callback-oriented functions. I'd rather see them be optimized > within specific contexts such as array_map() for significantly improved > performance *first* before recommending deprecation. > > It has more or less already been established that deprecating those function is pretty much impossible in the current state. > - gettype (more on this later [1]) > > https://github.com/search?l=PHP&o=desc&q=gettype&s=indexed&type=Code > > 9.3 million results. However, most results seem to be classes with a > method called getType(), so those again throw off an accurate global count. > I remember encountering this issue while I was first writting this email a month ago and couldn't get meaningfull results. > > Maths functions aliases: > > > > - getrandmax > > Shouldn't that have a comment like "(use mt_getrandmax() instead)"? > It should, > > - rand (use mt_rand instead) > > - srand (alias of mt_srand as of PHP 7.1) > > Most usages from searches seem to be using the mt_...() functions > already anyway. > Good to know > - is_writeable — Alias of is_writable > > https://github.com/search?l=PHP&o=desc&q=is_writeable&s=indexed&type=Code > > https://github.com/search?l=PHP&o=desc&q=is_writable&s=indexed&type=Code > > 629,500 vs. 3.65 million results. > > (On Google: 1.19 million vs. 6.2 million results for the words > writeable vs. writable.) > > Deprecating this alias seems petty. Users currently don't have to look > up the function at the moment. Removing the alias will cause EVERYONE > to look up the function to be sure they remember how to correctly spell > it to avoid the deprecation warning. > It may same petty but it was just an idea. Seems like it's to big of a hassle to convert. > Old signatures: > > > > - implode (historical signature) > > Impossible to run a search for this. > Understandable that this is impossible to search for. > > > Controversial idea: > > > > - deprecate array function creation (array()) > > https://github.com/search?l=PHP&o=desc&q=array&s=indexed&type=Code > > 71.1 million results. > > No. > > Also, array() is not a function. It's a keyword with performance on-par > with []. > > http://php.net/manual/en/reserved.keywords.php > > I also prefer array() over []. It's more readable because it uses a > *word* rather than unsearchable symbols to define a structure. > > Also, I get that arrays not actually implemented as such behind the > scenes but you simply can't deprecate an estimated 70 million lines of > code globally (and that's the code you can see, not including internal > software everywhere). "Hi, for PHP 8, we are going to fill your hard > drives via your application logs with deprecation warnings and crash > your servers. Have fun sorting that mess out!" > > Finally, barring a serious security vulnerability, keywords should be > viewed as permanent fixtures of the language. They can't be deprecated. > That's why there are so few keywords. Far too much userland code will > unnecessarily break. You suggest deprecating 'array' but not > 'enddeclare', 'endfor', 'endforeach', 'endif', 'endswitch', 'endwhile'. > All of those have alternative "shortcuts" but you didn't mention > deprecating those keywords even though there is far less usage compared > to 'array'. > In all honnesty, those keywords didn't even cross my mind because I have so rarely seen them. Now if people want to discuss if those should be deprecated or not I'm all for it But from the general vibe I get this seems like it is not going to go anywhere. Best regards George P. Banyard
