Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92966
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
To: internals@lists.php.net
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
Message-ID: <5723F4C4.6080207@garfieldtech.com>
Date: Fri, 29 Apr 2016 18:56:52 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: larry@garfieldtech.com (Larry Garfield)

On 04/29/2016 06:37 PM, Bob Weinand wrote:
> Hey,
>
>> Am 29.04.2016 um 21:58 schrieb Sara Golemon <pollita@php.net>:
>>
>> This is one of my favorites out of HackLang.  It's pure syntactic
>> sugar, but it goes a long way towards improving readability.
>> https://wiki.php.net/rfc/pipe-operator
> Thanks for proposing, so that I am able to show what I don't like about the |> pipe operator:
>
> In general, the pipe operator is hiding anti-patterns. It makes anti-patterns look nicer.
>
> Take the first example:
>
> $ret =
>    array_merge(
>      $ret,
>      getFileArg(
>        array_map(
>          function ($x) use ($arg) { return $arg . '/' . $x; },
>          array_filter(
>            scandir($arg),
>            function ($x) { return $x !== '.' && $x !== '..'); }
>          )
>        )
>      )
>    );
>
> Sure, it *looks* nicer with the pipe operator, if you really want to nest it. But that nesting is horrible in itself. It should be written as:
>
> $files = array_filter(scandir($arg), function ($x) { $x != '.' && $x != '..'; });
> $fullPath = array_map(function($x) use ($arg) { return "$arg/$x"; }, $files);
> $allFiles = array_merge($allFiles, getFileArg($fullPath));
>
> By limiting the nesting level to 2, the code gets itself much more readable and in addition, the variable names are self-explaining, so that you can jump right in.
> As already mentioned, the |> variant looks nicer than the above, but it still lacks the most important part; documentation in form of obvious variable names after each small step.
>
> It's always nice when code can look nicely, but this doesn't encourage writing understandable code. This RFC is just providing another way to shoot any future readers into the feet.
> Readers want to quickly grasp what is going on. Having to follow a whole list of operations whose result is written to a variable $ret is telling them absolutely nothing.
>
> TL;DR:
> -1: The |> pipe operator encourages a write-only style.
>
> Bob

I disagree.  The absence of an intermediate variable name does not 
inherently hinder readability/debuggability (nor does its presence 
inherently improve it).  It just makes more work for the code author to 
come up with potentially pointless variable names.

What I see in |> is an end-run around the "can't call methods on arrays 
because they're not collections" problem.  Viz, if we were dealing with 
an actual collection (as in Javascript, or many PHP libraries), we could 
do the following:

$ret = $scandir($arg)
   ->filter(function($x) { return $x !== '.' && $x != '..'; })
   ->map(function ($x) use ($arg) { return $arg . '/' . $x; })
   ->apply('getFileArg')
   ->merge($ret);

Which would be even nicer.  (This is also where the short-lambda 
proposal would come in useful.)  That's perfectly readable to me, and 
very clear what's happening.

My concern, if anything, is that |> feels more like a stop-gap hack 
around our clunky an uncomposable array handling rather than a solution 
to it.  I like the idea, I just wonder if we shouldn't fix the 
underlying problem and make functions better composable in the first place.

--Larry Garfield