On 2/6/2025 9:57 PM, 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. :-)
There's a song in here somewhere that goes:
♪♫♬ PHP continues turning into...symbol SOUUUUUUUP! [Oh no.] ♪♫♬
The main example provided in the RFC makes its own excellent argument
against the proposed feature:
$result = "Hello World"
|> 'htmlentities'
|> str_split(...)
|> fn($x) => array_map(strtoupper(...), $x)
|> fn($x) => array_filter($x, fn($v) => $v != 'O');
Symbols make languages harder to grok. I don't want a language like
COBOL where things that should sensibly be symbols are words but I also
don't want a code golfing language like APL that is just all the symbols
all day long. Language features should be able to be easily found via
search and every new symbol (or combination of symbols) is inherently
unsearchable on most/all search engines. That includes the search
engine on php.net. Go try searching for '...' or '=>' or '!=' operators
on php.net and you get...nothing! "Texture is the conductor of flavor."
-- French Chef Jean-Pierre. Balancing out symbols (liquids like water
which have no flavor) and words (meat and veggies packed with flavor) is
a language author's core responsibility in the language design soup kitchen.
While I'm not against adding symbols that serve a valuable purpose,
there is nothing to be gained by encouraging bad coding habits at the
outset. When a limitation is established up front such as "Functions
with more than one required parameter are not allowed" then users will
find ways to bypass the limitation such that it will kill performance in
favor of their perceived and flawed idea of "convenience." This
proposal will _minimally_ result in creating an anonymous function to
call any basic function with more than one required parameter but also
encourage abuse of the splat operator which should be used *exceedingly
sparingly*. What I mean by that is: Users will construct arrays
(expensive) to pass to anonymous functions with one parameter
(expensive) and then use the splat operator inside the anonymous
functions to unpack the input array to call the actual function (VERY
expensive). Whatever performance gains made by moving bad application
design into PHP core will be far outweighed by the abuse that naturally
follows to circumvent limitations. In fact, your own contrived example
usage includes two anonymous functions that call functions with more
than one required parameter! You are _already_ working around the known
limitations of *your own proposed feature* 🤦!! Why in the world would
you ever advertise that?! If that's not enough to kill an RFC before it
even goes to a vote, I don't know what is.
The repeated assignment to $temp in your second example is _not_
actually equal to the earlier example as you claim. The second example
with all of the $temp variables should, IMO, just be:
$temp = "Hello World";
$result = array_filter(array_map('strtoupper',
str_split(htmlentities($temp))), fn($v) { return $v != 'O'; });
By storing the result into $temp for each modification just so that you
can have multiline code, you are actually making the engine work harder
whereas a single statement saves the engine some unnecessary
refcounting/allocation/free work but accomplishes the same objective.
I'm nitpicking the clearly contrived second code example that didn't at
all improve my impression of the first example and where your own
example usage ended up exposing the fundamental flaws in the RFC. I
also consider the above compact code to be plenty readable and not
particularly necessary to span multiple lines, but that's obviously
subjective.
Just because someone _can_ do something doesn't mean that they should.
More than likely, users trying to do pipe-like operations in PHP
shouldn't be doing them in the first place.
--
Thomas Hruska
CubicleSoft President
CubicleSoft has over 80 original open source projects and counting.
Plus a couple of commercial/retail products.
What software are you looking to build?
