Re: [RFC] Pipe Operator

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