On 04/29/2016 06:37 PM, Bob Weinand wrote:
Hey,
Am 29.04.2016 um 21:58 schrieb Sara Golemon <poll...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
