Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127561
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 03 Jun 2025 10:41:08 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <f6be34cc-140a-4c9c-bbdf-ae443812eb09@app.fastmail.com>
In-Reply-To: 
 <CANTuiHsCRHKcALg71G7Suyeuq5G3ZYusDpYAArER4BV0d+E8+w@mail.gmail.com>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
 <CANTuiHsednV=Mh-XFT=c1axNyzpnFu1g6V2-WcRZnJnidUifaQ@mail.gmail.com>
 <c5c729b1-36f3-46b6-a502-12544e7842bc@app.fastmail.com>
 <CANTuiHsCRHKcALg71G7Suyeuq5G3ZYusDpYAArER4BV0d+E8+w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Jun 3, 2025, at 2:59 AM, Dmitry Derepko wrote:
>> 
>> Pipe and compose are importantly different operations.  I've had user-space implementations of both available for years in crell/fp:  https://github.com/Crell/fp/blob/master/src/composition.php
>> I'd love to have a compose operator natively in PHP, too.  The RFC for that is already written, just needs code.  I hope to formally propose it soon:  https://wiki.php.net/rfc/function-composition
> Hmm, that's great, but looks like we are missing something.
>
> 1. Would you propose the RFC to 8.5? I think it should be proposed with 
> the new pipe operator any way

I am working with someone on the implementation.  As soon as that's done I want to post it.  Whether it manages to get into 8.5 at this point is an open question.

> 2. RFC early feedback
>
> There is no big difference in DX with the new operator "+" for closures:
> - + operator may be overridden in some extensions and it also may 
> implement __invoke. What's expected behavior? It will be totally unclear

I expect the overlap there to be tiny, so it will rarely be encountered.  As to which "wins", I'd think probably the extension.

> - code examples from the rfc: https://3v4l.org/n7UB0 vs 
> https://3v4l.org/tOlft the first approach is better for me because it 
> may be batch-processed / combined / filtered / modified easily. So 
> taking my first message there are not so many changes: 
> https://3v4l.org/ncpEE
>
> Just try to imagine how to work with the composition and how it 
> perfectly works now: https://3v4l.org/ArK2O

If you want to do it that way, Crell/fp has you covered, have fun.  But the whole point of the RFC is to provide a native operator for concatenating functions.  Decomposing/deconcatenating an already composed function chain is... not a thing.  

> By the way, RFC describes userland "compose" function performance 
> problems, but there is no suggestion to make it natively, why so? 

Uh.  That's the entire point of the RFC?  Make a native compose operator that isn't even a function.  

--Larry Garfield