Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115174
MIME-Version: 1.0
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAF+90c-tnTMUyVDu=iheB3oL_Q6nuT+1aQgcw27xv_ZcQiDrkQ@mail.gmail.com> <45b16626-2b04-404b-f5f9-2430004bbdc8@telia.com>
In-Reply-To: <45b16626-2b04-404b-f5f9-2430004bbdc8@telia.com>
Date: Mon, 28 Jun 2021 16:52:05 +0200
Message-ID: <CAF+90c8MW-vaOP8CMadZii+Kro0DM1M_Kpup_A5AhDFQUFKX2w@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: PHP internals <internals@lists.php.net>, Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary="000000000000f7cf1d05c5d4a29c"
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f7cf1d05c5d4a29c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 21, 2021 at 4:26 PM Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.c=
om>
wrote:

> Den 2021-06-18 kl. 16:08, skrev Nikita Popov:
> > On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield <larry@garfieldtech.com>
> > wrote:
> >
> >> Hi folks.  The vote for the Partial Function Application RFC is now
> open,
> >> and will run until 30 June.
> >>
> >> https://wiki.php.net/rfc/partial_function_application
> >>
> >> Of particular note, a few people had asked about using ...? instead of
> ...
> >> for the variadic placeholder.  In the end we decided not to explore
> that,
> >> as Nikita explained off-list it was actually more confusing, not less,
> as
> >> it would suggest "placeholder for a variadic" rather than "a placehold=
er
> >> that is variadic."  Otherwise, it's just more typing.  The syntax
> choices
> >> section of the RFC has been updated accordingly.
> >>
> >
> > A couple of notes on the content (or non-content) of the RFC:
> >
> > * The behavior of nullsafe calls with PFA has been brought up in the
> > discussion, but is not mentioned in the RFC. For reference, $foo?->bar(=
?)
> > is the same as $foo !=3D=3D null ? $foo->bar(?) : null. I don't think t=
he
> > behavior is particularly unreasonable, but I also think it's not
> > particularly useful and may be surprising (in that there is a plausible
> > alternative behavior). I think you may have been better off forbidding
> that
> > case.
> >
> > * The behavior of parameter names / reflection with regard to variadic
> > parameters is very odd. For function test(...$args) and test(?, ?, ?) y=
ou
> > get back a function that nominally has three parameters with the name
> > $args. Parameter names in PHP are generally required to be unique, and =
of
> > course this also has implications for named arguments, for example this
> > works, while it probably shouldn't:
> > https://3v4l.org/cQITD/rfc#focus=3Drfc.partials To be honest, I'm not s=
ure
> > what the right way to handle this is, but I don't think this is it. A
> > possibility would be to bring back the concept of name-less parameters =
we
> > had prior to PHP 8 (for internal functions only), or possibly to make t=
he
> > signature less precise by simply retaining an ...$args parameter, and
> just
> > making the enforcement of "at least three parameters" an implementation
> > detail. The latter seems like the best option.
> >
> > * The RFC doesn't specify how PFA interacts with strict types. If I
> create
> > a partially-applied function in strict_types=3D1 file and call it in a
> > strict_types=3D0 file, what happens? Will it use strict_types=3D0 seman=
tics,
> > including for arguments that were bound in the strict_types=3D1 file?
> >
> > * It's worth noting that the "new Foo(?)" syntax will create and destro=
y
> a
> > Foo object as part of creating the partial (not just a call to the
> > partial). I've mostly convinced myself that this is *probably* harmless=
.
> It
> > would have interacted negatively with an earlier version of
> > https://wiki.php.net/rfc/new_in_initializers, but I think the problem
> there
> > was not on the side of partials.
> >
> > In any case, I'm voting no on this one: While PFA is simple on a
> conceptual
> > level, the actual proposal is complex and has lots of tricky edge cases=
.
> > Especially once you take a look at the implementation. I'm not convince=
d
> > that PFA in its full generality is justified for inclusion in PHP.
> >
> > Regards,
> > Nikita
> >
> Would you look on this feature in a different light if the above
> concerns about strict types and nullsafe calls could be clarified /
> solved? Or is it about the implementation with it's complexity and
> tricky edge cases?
>

These were just some notes on implementation details, they don't really
impact my overall opinion of the RFC. I should also say that I'm not
strongly opposed here, I'm just not convinced this is worthwhile :) The
complexity of the feature would be rather easy to overlook if I felt the
functionality was important.

I myself think one should take into account that this is a feature
> that would make PHP stand out even more. Not being a follower of
> other languages here :-)
>

Heh, it's the other way around for me: This just makes me more
apprehensive. Is there some special property of PHP that makes this feature
more relevant to us than other languages? All other mainstream languages do
well without this feature, so why do we need it?

Regards,
Nikita

--000000000000f7cf1d05c5d4a29c--