Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92963
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.106 as permitted sender)
Message-ID: <BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
In-Reply-To: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
Date: Sat, 30 Apr 2016 01:37:17 +0200
CC: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: bobwei9@hotmail.com (Bob Weinand)

Hey,

> Am 29.04.2016 um 21:58 schrieb Sara Golemon <pollita@php.net>:
>=20
> 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 =3D=20
  array_merge(
    $ret,
    getFileArg(
      array_map(
        function ($x) use ($arg) { return $arg . '/' . $x; },
        array_filter(
          scandir($arg),
          function ($x) { return $x !=3D=3D '.' && $x !=3D=3D '..'); }
        )
      )
    )
  );

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 =3D array_filter(scandir($arg), function ($x) { $x !=3D '.' && $x =
!=3D '..'; });
$fullPath =3D array_map(function($x) use ($arg) { return "$arg/$x"; }, =
$files);
$allFiles =3D 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=20=