I would say that this makes the entire functional approach: 1. more readable 2. easier to debug (woah, we can haz line numbers for failures!)
Here's the pseudo-code for a typical request/response dispatch cycle: $request = getGlobals() |> parseRequest($$) |> buildPsr7Request($$); $response = loadConfig() |> buildDic($$) |> getApp($$) |> getRouter($app) |> getDispatcher($$, $request) |> dispatchBusinessLogic($$, $request, new Response()) |> renderResponse($$) |> buildPsr7Response($$) |> emit($$); Here's what it would look like with a separate approach (more business-oriented): buildRequest() // (basically the first part of the previous example here) |> validate($$) |> convertToCommand($$) |> execute($$) |> convertToViewModel($$) |> render($$) |> convertToHttpResponse($$) |> emit($$) I think this is much more readable/clear than any event-driven or procedural approach. We know exactly what is going on, we will get clear stack traces (this could need some fine-tuning of the current PR - I didn't try it out yet) and we will be able to introduce intermediate steps with ease. In addition to all that, this will ease reactive programming by a lot, as piping is a natural fit for streams and all abstractions around streams. The syntax is also already effective in F# (you can write very expressive and easy to understand code with it) and now also landed in Hack. I'd say +10 to this proposal :D Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 30 April 2016 at 02:19, Stanislav Malyshev <smalys...@gmail.com> 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. > > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
