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