On Mon, 28 Jun 2021, 18:49 Levi Morrison, <levi.morrison@datadoghq.com>
wrote:
> On Mon, Jun 28, 2021 at 10:32 AM Olle Härstedt <olleharstedt@gmail.com>
> wrote:
> >
> > On Thu, 24 Jun 2021, 18:02 Larry Garfield, <larry@garfieldtech.com>
> wrote:
> >
> > > On Wed, Jun 16, 2021, at 11:16 AM, Larry Garfield 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
> > > > placeholder that is variadic." Otherwise, it's just more typing.
> The
> > > > syntax choices section of the RFC has been updated accordingly.
> > >
> > > Since some people still don't grok the use cases, I've written a blog
> post
> > > to make the case for them better than a detail-oriented RFC can.
> > >
> > >
> https://peakd.com/hive-168588/@crell/the-case-for-partials-and-pipes-in-php
> > >
> > > There has also been some positive Twitter chatter, as well as the
> level of
> > > +1s on that post (which is, I think, the highest of any PHP post I've
> had
> > > on there, ever), so I think the demand for it is definitely there in
> the
> > > ecosystem. It's just not people who frequent Internals. :-/
> > >
> > > I'd say there are definitely people that want to use partials.
> > >
> > > --Larry Garfield
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> > Out of curiosity, what would it take to implement function aliasing in
> PHP?
> > To enable a limited form of pipes, like foo |> bar.
> >
> > Olle
>
> We probably could special case it for pipes; it's more of a matter if
> we _should_. But, to do it generally so that things like
> array_map(strlen, $arr) work is not trivial. The main issue is that
> different symbol types have separate "tables", if you will. The engine
> decides to look in one bucket or another based on the syntax. In this
> case, based on syntax the engine will look in the constant table for
> strlen, as strlen in array_map(strlen, $arr) is a
> constant
> lookup by syntax.
>
> If we want it to fall-back to looking in other tables, then we'd have
> to deal with various challenges:
> 1. We have to deal with symbol collisions that exist today somehow,
> such as if strlen exists both as a function and a constant, or if
> $this->count exists as both a property and a method. I would prefer
> to do the simple thing and forbid collisions, but there are other
> strategies.
> 2. How do we handle the fact that different symbol types behave
> differently in namespaces when the symbol doesn't exist?
> 3. Also, how do we handle differences in case sensitivity between symbol
> types?
>
> Personally, I think it's worth it to change all of these things,
> because it could also give us function and constant autoloading. Of
> course, we'd have to get 2/3 of voters to agree on solutions to these
> things, which probably includes some backward-compatibility breaks so
> that might be difficult. But, nobody has tried so maybe not.
>
Right. So you'd have to add a resolve sympol type routine, and if it
returns "this is a function/method", strlen would evaluate to be wrapped in
a lambda? Then the problem would be the overall performance cost of such a
routine, and to deal with collisions, as you said. Hm.
Well, couldn't another alternative be that pipe operator assumes a callable
it can wrap on its right side? This wouldn't allow the array map use case,
but it would allow others. A third alternative would be to type-cast to
callable, perhaps.
array_map((callable) strlen, $arr);
This would be a shorter version of manually writing out the wrapping
lambda. But there's already fn, so. No big benefit.
Olle