Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114553
To: internals@lists.php.net
References: <CAF+90c_iYjsDWoqPaDtavVgj2WFdpiuBmGeQZFAqokVoVZTxoA@mail.gmail.com>
 <CALfTnfXDTvrtA9-hN+UH+qs3iS9q34jseunBD7YumGkonrSwXA@mail.gmail.com>
 <CAF+90c9DpTWzqu9S9=CkuaW=RnbneXUbRbqhuJDRBPwUz9RMsA@mail.gmail.com>
 <CAC5V6ghco1H4jT2Y_ug3LTWfyAz_5f6iCObGrdDfXn2PeuXgLg@mail.gmail.com>
 <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com>
Message-ID: <54744b98-27de-4562-d243-77d9e5cba7a9@gmx.net>
Date: Fri, 21 May 2021 11:09:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <fa269b69-9bac-4a81-8c65-409766f1c9f8@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Subject: Re: [PHP-DEV] [RFC] First-class callable syntax
From: a.leathley@gmx.net (Andreas Leathley)

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 par=
ameter from the underlying function" and "copy all remaining parameters fr=
om the underlying function" is not viable.  It runs into oddball cases whe=
re you may intend to only use one argument but end up using multiple, espe=
cially in array operation functions that sometimes silently pass keys alon=
g to callbacks if they can.  Hence the separate ? and ... that were propos=
ed.
>
> * 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 ap=
plication, 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 lib=
rary (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://w=
iki.php.net/rfc/pipe-operator-v2).
>
> While there are other use cases, the two of those cover the vast majorit=
y 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 "? me=
ans zero or more".  We also went down a rabbit hole of trying to make argu=
ment 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 symbol=
s and drops named placeholders.  It doesn't give us every possible combina=
tion, 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, whic=
h 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 leas=
t I assume we all do), and lots of additional power to boot.  I'd rather s=
ee us try to drive PFA home to completion.  If that proves impossible by e=
arly 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 wh=
ich 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 =3D 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 =3D new Product($dependency1, $dependency2, ...);
$productObjects =3D 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.