Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127552
Precedence: bulk
MIME-Version: 1.0
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>
In-Reply-To: <c5c729b1-36f3-46b6-a502-12544e7842bc@app.fastmail.com>
Date: Tue, 3 Jun 2025 10:59:18 +0300
Message-ID: <CANTuiHsCRHKcALg71G7Suyeuq5G3ZYusDpYAArER4BV0d+E8+w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000009bb25c0636a642c3"
From: xepozzd@gmail.com (Dmitry Derepko)

--0000000000009bb25c0636a642c3
Content-Type: text/plain; charset="UTF-8"

>
>
> 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
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
- 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

By the way, RFC describes userland "compose" function performance problems,
but there is no suggestion to make it natively, why so?

--

Best regards,
Dmitrii Derepko.
@xepozz

--0000000000009bb25c0636a642c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br clas=
s=3D"gmail-Apple-interchange-newline">Pipe and compose are importantly diff=
erent operations.=C2=A0 I&#39;ve had user-space implementations of both ava=
ilable for years in crell/fp:=C2=A0=C2=A0<a href=3D"https://github.com/Crel=
l/fp/blob/master/src/composition.php" rel=3D"noreferrer" target=3D"_blank">=
https://github.com/Crell/fp/blob/master/src/composition.php</a></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex"><br class=3D"gmail-Apple=
-interchange-newline">I&#39;d love to have a compose operator natively in P=
HP, too.=C2=A0 The RFC for that is already written, just needs code.=C2=A0 =
I hope to formally propose it soon:=C2=A0=C2=A0<a href=3D"https://wiki.php.=
net/rfc/function-composition" rel=3D"noreferrer" target=3D"_blank">https://=
wiki.php.net/rfc/function-composition</a></blockquote><br class=3D"gmail-Ap=
ple-interchange-newline"><div dir=3D"ltr">Hmm, that&#39;s great, but looks =
like we are missing something.<div><br></div><div>1. Would you propose the =
RFC to 8.5? I think it should be proposed with the new pipe operator any wa=
y</div><div>2. RFC early feedback</div><div><br></div><div>There is no big =
difference in DX with the new operator &quot;+&quot; for closures:</div><di=
v>-=C2=A0+ operator may be overridden=C2=A0in some extensions and it also m=
ay implement __invoke. What&#39;s expected behavior? It will be totally unc=
lear</div><div>- code examples from the rfc:=C2=A0<a href=3D"https://3v4l.o=
rg/n7UB0">https://3v4l.org/n7UB0</a> vs=C2=A0<a href=3D"https://3v4l.org/tO=
lft">https://3v4l.org/tOlft</a> the first approach is better for me because=
 it may be batch-processed / combined / filtered / modified easily. So taki=
ng my first message there are not so many changes:=C2=A0<a href=3D"https://=
3v4l.org/ncpEE">https://3v4l.org/ncpEE</a></div><div><br></div><div>Just tr=
y to imagine how to work with the composition and how it perfectly works no=
w:=C2=A0<a href=3D"https://3v4l.org/ArK2O">https://3v4l.org/ArK2O</a></div>=
</div><div class=3D"gmail_quote gmail_quote_container"><div>=C2=A0=C2=A0</d=
iv><div>By the way, RFC describes userland &quot;compose&quot; function per=
formance problems, but there is no suggestion to make it natively, why so?=
=C2=A0</div></div><div><br></div><span class=3D"gmail_signature_prefix">--<=
/span><div><br></div><div><span class=3D"gmail_signature_prefix"></span>Bes=
t regards,<br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr">D=
mitrii Derepko.</div><div><a class=3D"gmail_plusreply" id=3D"plusReplyChip-=
1">@xepozz</a><br></div></div></div></div>

--0000000000009bb25c0636a642c3--