Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109905
MIME-Version: 1.0
References: <2677cdc6-309c-4e4e-9cd9-12ff2a90c1e1@www.fastmail.com>
 <93A509E9-E6BC-425C-A584-F49F094E75B0@benramsey.com> <CAESVnVpzB-m8MCkCm-Nt1tRSUyZQ_320W3b5gyi3ymMPuvrU-g@mail.gmail.com>
 <b13c0d2c-9407-4651-8ec7-0dd9b6550901@www.fastmail.com> <46adaf3a-be5b-4eaf-b2fd-7243d00200e1@www.fastmail.com>
In-Reply-To: <46adaf3a-be5b-4eaf-b2fd-7243d00200e1@www.fastmail.com>
Date: Wed, 29 Apr 2020 09:44:47 +0200
Message-ID: <CAF+90c85sKi1SHfGQeA8BrfeoWaTJoTu8cJmda90NnyXCp-tPg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000003f665a05a4692020"
Subject: Re: [PHP-DEV] [RFC] Function pipe operator
From: nikita.ppv@gmail.com (Nikita Popov)

--0000000000003f665a05a4692020
Content-Type: text/plain; charset="UTF-8"

On Wed, Apr 29, 2020 at 2:35 AM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Tue, Apr 21, 2020, at 9:43 AM, Larry Garfield wrote:
>
> > On Mon, Apr 20, 2020, at 11:06 PM, Sara Golemon wrote:
> > > Happy with the revival, and I do want to underline the "Future Work"
> > > section about Partial Functions.  PF will make this version of pipes
> 100%
> > > more readable and fluent, and I want to endorse both, but I'll take
> one at
> > > a time.
> >
> > I agree that the pipe operator relies on having a "good" (subjective)
> > way to reference callables, which is a weakness of PHP right now.  We
> > discussed that in depth a few months ago as well.
> >
> > IMO, short-lambdas in 7.4 are "good enough" to make the pipe operator
> > useful.  They're not ideal, but they're sufficient.
> >
> > Levi's partial application RFC would be close enough to ideal; You
> > could reference an already-single-parameter or multi-parameter function
> > lexically without any string parsing silliness, which means namespace
> > resolution works, and it could potentially be optimized to avoid an
> > extra layer of function call.  It would be even better than ::function,
> > IMO, because you can provide it with closed-over variables at the same
> > time.  It sounds like we all want that.
> >
> > I do not believe that should block the pipe operator, however.  This is
> > a case where two independent RFCs should be able to stand on their own
> > but create a "sum is greater than their parts" situation, which is a
> > good thing.
> >
> > If anyone has bandwidth, I'm happy to collaborate on the PF RFC as
> > well.  It's out of my solo skillset right now (frankly so was pipe
> > until this weekend), but if someone is able to provide
> > hand-holding/pairing I'm willing to work on that, too, either now in
> > parallel or after pipe lands.  Both should happen, but I don't think
> > either should block the other.
>
> Just an update: I've tweaked the patch based on feedback from a few
> folks.  The precedence now seems to be where it is most logical (to me),
> and I've changed what the flag is on the AST node based on a recommendation
> from Nikita (assuming I understood him correctly).  I think it's in an
> acceptable final state at the moment baring any further feedback on GitHub.
>
> It sounds like the only negative pushback at the moment is "can we do
> partial application first?"  Which... I'd love to but we need help on that.
> :-)  (Volunteers welcome.)  Is there any other pushback?
>
> How do people feel about putting this to a vote sometime next week?  I
> don't know how long I want to sit on it waiting to see if we can pull off
> partial application.  I also want the partial application RFC, for reasons
> stated, but still feel that both are beneficial enough to stand on their
> own and it doesn't really matter which happens first.
>

I think it's pretty unlikely that this RFC will pass without having partial
application first. I understand that the features are technically
orthogonal, but in terms of coding style, none of the examples given in the
RFC would pass code review (from me). They either use PHP's ugly callable
syntax, or they use arrow functions, in which case you could just as well
store the value in a temporary $x, rather than using an fn($x) function
combined with the pipe operator. As-is, I don't think the pipe operator
would constitute an improvement over the status quo.

So... feel free to start voting, but don't get expectations too high ;)

Small note on the RFC text: The line

    |> fn($x) => array_map(fn($v) => 'strtoupper', $x)

should probably be just

    |> fn($x) => array_map('strtoupper', $x)

Regards,
Nikita

--0000000000003f665a05a4692020--