Re: [RFC] Pipe Operator

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