Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126339
Message-ID: <38b57201-5091-4c68-988b-9ce3beac8fcb@cubiclesoft.com>
Date: Fri, 7 Feb 2025 10:59:13 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Pipe Operator (again)
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <de8140ab-0941-45cd-ba20-4aece2f69aea@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: thruska@cubiclesoft.com (Thomas Hruska)

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?