On 04/29/2016 07:19 PM, Stanislav Malyshev wrote:
Hi!
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
I think this takes the syntax too much towards Perl 6 direction. There
is a lot of fun in inventing cool signs like |> and making them do
nontrivial cool stuff. There's much less fun when you try to figure out
what such code is actually doing - and especially why it is not doing
what you thought it is doing. Brian Kernigan once said:
"Everyone knows that debugging is twice as hard as writing a program in
the first place. So if you're as clever as you can be when you write it,
how will you ever debug it?"
I think this applies not only to debugging, but also to reading programs
in general. If we are "as clever as we can be" with syntax, the program
becomes unreadable.
For this feature specifically, I see nothing wrong with assigning
intermediate results to variables - moreover, I see an advantage to it
both in reading (you tell people what you expect to have happened in
this stage) and in debugging (you can actually *see* what happened and
*check* whether what you thought should be happening actually happened).
If we could achieve the elegance of Unix pipes, I'd agree that it is
simple enough that we can see what is going on - but having it rely on
two magic things which are in different part of expression and
context-dependent ($$ means different things in different places) is too
much for me.
See, I take that quote in the exact opposite direction. I find chaining
methods to be far, far less "clever" than deeply nesting them inside
each other. We shouldn't force pointless intermediate variables on
people for the sake of readability. The fair comparison is the deeply
nested version vs. the chained version, and in that comparison the
readability of the chained version is far, far better.
Lester pointed out error handling and branching. True, the pipe
chaining wouldn't handle that, but it doesn't claim to. Neither does
directly nesting the function calls inside each other. If you do need
to pause, examine a value, and branch, then yes that's where you want an
intermediate variable to analyze and nothing has changed. However,
passing an array to array_filter() then passing the result to
array_map() is always type safe (because array_filter still returns an
array even if it filters down to 0 items), and array_map on an empty
array is essentially a no-op, so I'm comfortable doing so, and wish I
could do so more often with less fugly syntax. :-)
In a way... Sara, this syntax feels like it's only one step removed from
promises; if any of the chained steps involve IO, it becomes basically
what promises are for. Am I barking down the wrong tree, or is there
something we could connect there? (I don't mean "reject this in favor
of promises", but more "is there something we can do here to be forward
thinking, since lots of people want to see async in core PHP?")
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
