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
<la...@garfieldtech.com <mailto:la...@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>
