Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114989
To: Joe Watkins <krakjoe@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>,
 Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
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>
 <CAOwTYAvmGVvKn8zJEr--pLSDwL3_AuEn_daEiP-PMLZAQBhb4g@mail.gmail.com>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
Message-ID: <8ec11744-6cb7-5a88-4ad7-22b825c7fecf@telia.com>
Date: Mon, 21 Jun 2021 22:34:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAOwTYAvmGVvKn8zJEr--pLSDwL3_AuEn_daEiP-PMLZAQBhb4g@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------6E81C6B55551B03EA4B46C62"
Content-Language: en-GB
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: internals@lists.php.net ("Björn Larsson via internals")

--------------6E81C6B55551B03EA4B46C62
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi and thanks for the clarification!

So if I get it right, by not addressing null safe calls and strict types 
now we can address it later when we know a little bit more, which btw is 
not the first time it's done. And the feature proposed requires a non 
trivial implementation.

I think it should be noted that this is a feature where PHP is in the 
forefront of language development, not a follower.

Of course it requires some afterthought, which I think the RFC fulfils 
giving a broad explanation on  why it is like it is. Maybe a bit weak on 
the use cases, besides Pipe operator that would benefit from this feature.

So I hope it passes, +1 from me (not having a vote though).

Regards //Björn L

Den 2021-06-21 kl. 18:27, skrev Joe Watkins:

> I'd like to note a couple of things ...
>
> The behaviour of nullsafe and strict types being unspecified in the 
> RFC would allow us to solve those problems later.
>
> The behaviour of strict types right now is objectively wrong, the 
> partial takes strictness from the application site, so as Nikita 
> already knew when he asked the question; calls from a non-strict file 
> will not behave as you expect.
>
> With regard to the complexity in the implementation: I think it's 
> important to understand that the complexity of the implementation is a 
> product of the semantics we landed on during discussion.
>
> The first implementation where we only had ? was technically simpler, 
> but not intuitive from a user perspective.
>
> Now we have semantics that are easy to understand, that you can 
> communicate in a few lines. But the implementation is necessarily 
> complicated as a result of those semantics.
>
> We also have to remember that this is actually some kind of middle 
> ground, it's not the most complicated version of partial application 
> we could have - because that most complicated version would also 
> include support for re-ordering parameters (named placeholders), and 
> nor is it the simplest which offloaded a lot of (cognitive) overhead 
> onto the programmer.
>
> The question is not can we simplify the implementation, the question 
> is rather, is the necessary complexity of an implementation with the 
> kind of semantics that are desirable justified.
>
> Cheers
> Joe
>
>
>
>
> On Mon, 21 Jun 2021 at 16:26, Björn Larsson via internals 
> <internals@lists.php.net <mailto:internals@lists.php.net>> 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 <mailto: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
>     <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
>     placeholder
>     >> 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 !== null ? $foo->bar(?) : null. I don't
>     think the
>     > 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(?,
>     ?, ?) you
>     > 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=rfc.partials
>     <https://3v4l.org/cQITD/rfc#focus=rfc.partials> To be honest, I'm
>     not sure
>     > 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 the
>     > 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=1 file and call it in a
>     > strict_types=0 file, what happens? Will it use strict_types=0
>     semantics,
>     > including for arguments that were bound in the strict_types=1 file?
>     >
>     > * It's worth noting that the "new Foo(?)" syntax will create and
>     destroy 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
>     <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
>     convinced
>     > 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?
>
>     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 :-)
>
>     Regards //Björn L
>
>     -- 
>     PHP Internals - PHP Runtime Development Mailing List
>     To unsubscribe, visit: https://www.php.net/unsub.php
>     <https://www.php.net/unsub.php>
>

--------------6E81C6B55551B03EA4B46C62--