Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114507
MIME-Version: 1.0
References: <f3d20496-c560-42b7-9a0d-8672b3cafa7d@www.fastmail.com>
 <1565EB81-57B7-49B0-A47C-342E0088A432@trowski.com> <CAN2symhHys1uADWnOfraEA3SiM8_57=JttWhgOJ0Kh7nwt4R+g@mail.gmail.com>
 <CAEMvS4FbtPqdeySsVWm=Gub1BNiv+OCiB2oGL-+aZvBH7hmisA@mail.gmail.com>
 <CAEMvS4F+AbxPJQ5ctLONptECvmkdrzT42oU4rDOjtD2dC_jEJw@mail.gmail.com>
 <09B663C3-E21D-432B-BB7F-78312F827C30@newclarity.net> <CAC5V6gjDfqxBPYF_ejVTboPOGV9rg0ArAqOGGO3mPG6nqEPevw@mail.gmail.com>
 <CAAKU0u=ssfSbHHdxgWgEHT0a+0iMKvdtJbWT6OFw9mNtfPWt4Q@mail.gmail.com>
 <CAC5V6gikd-vEmiY-XUH-CHPVEXBsLTebYho5H7880OWemy_-Zw@mail.gmail.com> <CAAwdEzBhR+hPLkRORa_pPZV-kqJdNNnJS23aPKjJ2xO-DKhU3g@mail.gmail.com>
In-Reply-To: <CAAwdEzBhR+hPLkRORa_pPZV-kqJdNNnJS23aPKjJ2xO-DKhU3g@mail.gmail.com>
Date: Mon, 17 May 2021 18:52:58 +0200
Message-ID: <CAC5V6ghuTwbZPcPUThWf+1LmHvRKB8ZvHJfTcgr1QMmmmioaFg@mail.gmail.com>
To: =?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?= <drealecs@gmail.com>
Cc: Levi Morrison <levi.morrison@datadoghq.com>, Mike Schinkel <mike@newclarity.net>, 
	Hossein Baghayi <hossein.baghayi@gmail.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b254f505c2896df7"
Subject: Re: [PHP-DEV] [RFC] Partial function application
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--000000000000b254f505c2896df7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, May 17, 2021 at 5:47 PM Alexandru P=C4=83tr=C4=83nescu <drealecs@gm=
ail.com>
wrote:

>
> On Mon, May 17, 2021 at 6:36 PM Guilliam Xavier <guilliam.xavier@gmail.co=
m>
> wrote:
>
>> On Mon, May 17, 2021 at 5:01 PM Levi Morrison <
>> levi.morrison@datadoghq.com>
>> wrote:
>>
>> > Joe Watkins has successfully worked out some bugs that also enable
>> > more powerful behavior. Thanks to Nikita and any others who worked
>> > with Joe on fixing these issues and reviewing the PR.
>> >
>> > The short of it is that re-ordering parameters when using named
>> > placeholders is now technically possible. We will send an update when
>> > the RFC and implementation are ready for re-review.
>> >
>>
>> That's great news!
>>
>> By the way, I forgot to add that another syntax might also be clearer wh=
en
>> binding a value to a named parameter, e.g.:
>>
>> ```
>> function f($a, $b, $c, $d, $e) {/*...*/}
>>
>> /* We want to bind value 4 to param "d" */
>>
>> // with current syntax:
>> $p =3D f(?, d: 4); /* or f(?, ?, ?, 4) */
>>
>> // with another hypothetical syntax:
>> $p =3D *f(d: 4);
>> ```
>>
>> Anyway, looking forward to your update =3D)
>>
>> Thanks,
>>
>> --
>> Guilliam Xavier
>>
>
> Hey Guilliam,
>
> adding a special character like * or ? before the function name is
> not going to work.
> It might look good for *f() but it has the same issues as casting.
>
> You should be able to have with the current version a code like
> $actionGenerator->getDriveAction()('home', ?)
> You can't really put the * or ? before the function name here.
>
> Maybe having it just before the parenthesis would work.
>
> Regards,
> Alex
>
>
>
>
Hey Alex,

I was thinking of a (special) new unary [prefix] operator (e.g. `*` which
currently only exists as binary) with a higher precedence than `()` (if
that makes sense), which indeed means that e.g. `*f(1)(2)` would be like
current `f(1, ?)(2)`, and `f(1)(2, ?)` would require wrapping as
`*(f(1))(2)`.
A lower precedence would require wrapping as `(*f)(1)` for the simple case
(i.e. most of the time), which moreover would probably be problematic if
you have both a `function f` and a `const f`.

Just before the affected `(` might also work indeed, but with another
symbol, as `f(1)*(2)` [and `f*(1)`] already means `f(1) * 2` [and `f *
1`].  Maybe `!`, `@` or `~` would be unambiguous at that position?

(For both, there's also the possibility of choosing not a symbol but a
keyword...)

Alternatively, `f(..., d: 4)` or probably rather `f(d: 4, ...)` would
arguably still be clearer than the current `f(?, d: 4)`, but still wouldn't
really solve the "weirdness" of `noParam(...)` and `threeParams(1, 2, 3,
...)`.

Sorry, I didn't intend to diverge so much.  The gist is that I (too) don't
like the current "duality" of `?`.

PS: when I write "current" I really mean "in the current state of the RFC".

Regards,

--=20
Guilliam Xavier

--000000000000b254f505c2896df7--