Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126335
Precedence: bulk
MIME-Version: 1.0
Date: Fri, 07 Feb 2025 17:15:19 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
In-Reply-To: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
User-Agent: Roundcube Webmail/1.4.8
Message-ID: <17d2962d351ee181ec05fb45544accd4@glaive.pro>
Organization: SIA "Glaive.pro"
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: juris@glaive.pro (Juris Evertovskis)

On 2025-02-07 06:57, Larry Garfield wrote:
> Hi folks.  A few years ago I posted an RFC for a pipe operator, as seen 
> in
> many other languages.  At the time it didn't pass, in no small part
> because the implementation was a bit shaky and it was right before 
> freeze.
> Nonetheless, there are now even more (bad) user-space implementations 
> in
> the wild, as it gets brought up frequently in "what do you want in 
> PHP?"
> threads (though nowhere near generics or better async, of course), so 
> it
> seems clear there is demand in the market for it.
> 
> It is now back with a better implementation (many thanks to Ilija for 
> his
> help and guidance in that), and it's nowhere close to freeze, so here 
> we
> go again:
> 
> https://wiki.php.net/rfc/pipe-operator-v3
> 
> Of particular note, since the last RFC I have concluded that a compose
> operator is a necessary complement to a pipe operator.  However, it's 
> also
> going to be notably more work, and the two operators don't actually
> interact at all at the code level, so since people keep saying "Small
> RFCs!", here's a small RFC. :-)

Great feature! Three questions and a comment from me.

1. Do you think it would be hard to add some shorthand for `|> 
$condition ? $callable : fn($😐) => $😐`?
2. Is compose in the scope or not? You mention it in both the main RFC 
body and the future scope. Or are those different composes?
3. Does the implementation actually turn `1 |> f(...) |> g(...)` into 
`$π = f(1); g($π)`? Is `g(f(1))` not performanter? Or is the engine 
clever enough with the var reuse anyways?


I don't think Laravel's pipeline is relevant here.  In it each callback 
is responsible for invoking the rest of the chain. Thus it allows early 
returns and interacting with the return value of the following chain 
(`return 5 + $next($v)`). More like a middleware chaining tool, not a 
pipe in the same meaning as in this RFC.

BR,
Juris