On 20.05.21 21:35, Larry Garfield wrote:
There's been a lot of rapid iteration, experimentation, and rejection.
The most recent alternatives are this one from Levi:
https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd
And this one from me:
https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8
The main takeaways (to give context to Nikita's proposal):
* Because of optional arguments, using the same symbol for "copy one parameter from the
underlying function" and "copy all remaining parameters from the underlying
function" is not viable. It runs into oddball cases where you may intend to only use one
argument but end up using multiple, especially in array operation functions that sometimes silently
pass keys along to callbacks if they can. Hence the separate ? and ... that were proposed.
* Named arguments make things more complicated. One of the questions is
whether named placeholders should be supported or not. And if they are, does
that mean you can effectively reorder the arguments in the partial application,
and what does that mean for usability. It gets complicated and scope-creepy
fast.
* The most important use cases are:
** "prefill nothing, just give me a callable" (which is the case Nikita's RFC
covers)
** "reduce an arbitrary function to a single remaining argument", which lets it
be used by various existing callback functions in the standard library (array_map,
array_filter, etc.), many user-space APIs, and the pipes RFC that I am planning to bring
back up once PFA is figured out (https://wiki.php.net/rfc/pipe-operator-v2).
While there are other use cases, the two of those cover the vast majority of
uses. (There is some dispute about which of those is larger, or will be larger
in the future.)
It took a while to realize the first point, which basically killed "? means zero or
more". We also went down a rabbit hole of trying to make argument reordering work
because some people asked for it, but as noted that's a very deep rabbit hole.
My gist above was a reduced-scope version of Levi's that uses two symbols and
drops named placeholders. It doesn't give us every possible combination, but
it does give us most reasonable combinations.
Nikita's "just do the first one" RFC (this thread) was proposed at about the
same time, and takes an even-further scope reduction.
My own take is that the PFA discussion has been overly-bikeshedded, which is unfortunate
since I think we're quite close to now having a workable answer that covers most
reasonable use cases. While I agree Nikita's RFC here would be an improvement over 8.0,
I don't think throwing in the towel on PFA yet is a good idea. It's a much more robust
and powerful approach that still gets us the "first class callable" syntax we
all want (at least I assume we all do), and lots of additional power to boot. I'd rather
see us try to drive PFA home to completion. If that proves impossible by early July,
then this RFC would still get us something this cycle, as long as the syntax is still
compatible with PFA. (Otherwise whenever PFA gets sorted out in the future we end up
with yet-more-ways to do the same thing that are not optimizations of each other but just
competing syntax, in which case no one wins.)
I think Levis proposal and the two symbols ... and ? are a really good
improvement to the previous PFA RFC (Nikitas/Joes RFC is a good first
step in that direction). I do think named arguments are important, but
reordering arguments could be confusing and are not necessary (and if
named arguments are used for the PFA, it would make sense to use named
arguments for calling it too).
Another big reason for me why I like Levis proposal more is that he
still includes partially applying the new operator. Although the
semantics of the new operator are a bit different from regular
functions, it would be very handy to support this special case.
array_map is an obvious application:
$productObjects = array_map(new Product(?, ?, ?), $productIds,
$currencies, $prices);
But other usages would probably pop up, like abstracting away
dependencies of classes by pre-setting those via PFA, like:
$productFactory = new Product($dependency1, $dependency2, ...);
$productObjects = array_map($productFactory, $productIds, $currencies,
$prices);
I really like this because from a users perspective this seems very
clear and readable to me, even though from the PHP language perspective
it might be more messy.
About the bikeshedding: Using "..." as a symbol does make sense to me,
as variadic unpacking/variadic arguments have a similar connotation
(referring to an unknown/arbitrary amount of elements). * was also
suggested (as in "somefunction(*)" instead of "somefunction(...)"), and
I like that too - * in regex is any amount of elements (even zero), and
? is exactly one placeholder in SQL. As many PHP developers know regex
and SQL this would make PFA code a lot easier to understand even if
someone is not that familiar with it yet.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
