Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92967
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain thomasbley.de from 85.13.128.151 cause and error)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: ALL-INKL Webmail 2.11
In-Reply-To: <BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com><BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
To: pollita@php.net, bobwei9@hotmail.com
Cc: internals@lists.php.net
Message-ID: <20160429235441.0A00E1A821B0@dd1730.kasserver.com>
Date: Sat, 30 Apr 2016 01:54:40 +0200 (CEST)
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: mails@thomasbley.de ("Thomas Bley")

Hey,

to me recursion and pipe operator looks really hard to read, I guess this is faster and better readable:

foreach (scandir($arg) as $x) {
  if ($x == '.' || $x == '..') {
    continue;
  }
  $x = $arg . '/' . $x;
  // inline getFileArg ...
  $allFiles[] = $x;
}

Regards
Thomas


Bob Weinand wrote on 30.04.2016 01:37:

> 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 
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>