Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93012
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.161.170 cause and error)
MIME-Version: 1.0
In-Reply-To: <5723F4C4.6080207@garfieldtech.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
	<BLU436-SMTP216F49282378CD9E3E13863E2660@phx.gbl>
	<5723F4C4.6080207@garfieldtech.com>
Date: Sun, 1 May 2016 00:20:45 +0100
Message-ID: <CA+kxMuQbsydVkU4xG14STs=8pBYVbMtacA-sNfuEe4qh+xbM0Q@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, Sara Golemon <pollita@php.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: danack@basereality.com (Dan Ackroyd)

Hi Sara,

I have to take exception to the section of the RFC titled "File
collection Example", where you take a block of code and re-write it to
be more readable, using the RFC's syntax.

However, it is not the proposed new syntax that makes the code more
readable - it is solely due to writing it in the correct order that
makes the code more readable. This can be done using current PHP
syntax, so that the code is:

$dirEntries = scandir($arg);
$files      = array_filter($filesAndDirectories, function($x) { return
$x !== '.' && $x != '..'; });
$fullPaths  = array_map(function ($x) use ($arg) { return $arg . '/' .
$x; }, $files)
$fileInfo   = getFileArg($fullPaths);
$ret        = array_merge($ret, $fileListInfo);

Using the proposed new syntax to rewrite it without the intermediate
variables like this.

$ret = scandir($arg)
    |> array_filter($$, function($x) { return $x !== '.' && $x != '..'; })
    |> array_map(function ($x) use ($arg) { return $arg . '/' . $x; }, $$)
    |> getFileArg($$)
    |> array_merge($ret, $$);

Does not now show a marked improvement in readability.

Showing the benefits of an RFC by comparing 'apples to oranges', is at
least to some extent 'pulling a fast one'. Do you have any examples
where the original code is not terrible, that show an increase in
readability? (By implication, I am not persuaded by the PSR 7 ones.)

Larry Garfield wrote:
> The absence of an intermediate variable name does not inherently hinder readability/debuggability (nor does its presence inherently improve it).

I disagree strongly, the presence of intermedite variables does help
the code be more understandable. It gives semantic meaning to the
steps in involved in the process, as well as giving variables that can
be watched in a debugger.

If people want the excitement of not being able to figure out what the
intermediate variables mean, then they can already do so by using
terrible variable names.

From the first "PSR7 Example", we could write the code like:

$v = getGlobals();
$v = parseRequest($v);
$request = buildPsr7Request($v);

If you truly believe that not having semantically meaningful
intermediate variable names, you would have no problem with code being
written like this, right?

Personally, I always use semantically meaningful variable names, as
they make life so much easier for any person who needs to read the
code.

cheers
Dan