Le 14/05/2016 à 18:35, Sara Golemon a écrit :
On Sat, May 14, 2016 at 3:33 AM, François Laupretre <franc...@php.net> wrote:
Le 14/05/2016 à 01:36, Simon Welsh a écrit :
\>> Sure, you could try to use the type of the value being passed in,
but that ends up much more magic and then you run into the same
problem with strpos, or password_verify, or a variety of other
functions that take multiple of the same type of argument where
order matters.

Right. Some functions may have several potential arguments to substitute. In
this case, I propose we choose a position to use when the function is used
in a pipe and, then, create function aliases with different positions.

This doesn't strike you as massively over-engineered (and magic)
compared to letting the caller explicitly specify position?

Moreover, it only "solves" the argument ordering problem by replacing
it with a function alias selection problem.

No. Not *massively* over-engineered because we have only few cases. More than 95 % of existing functions provide only one potential lhs. So, yes, we would have to create some function aliases, but I estimate we don't need more than 10 to 20 overall. So, on one side, I solve the argument ordering problem for 2,000+ functions, and on the other side, I probably need to create about 20 function aliases. IMO, the balance is still positive.

Another point is that we don't need to create an extensive set of function aliases immediately. ATM, we just need to choose one lhs arg per function. Then, in a future version, an alias can be proposed if another potential lhs appears useful. I'll take strpos() as an example : IMO, the 'natural' lhs is $haystack. This allows to release the 'pipe' feature without creating anything else. Then, in a future version, if someone wants to propose an alias which would use $needle as lhs, it will the object of an additional RFC and we'll discuss the alias name, and whether it is really needed or not.


Regards

François


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to