I like the proposal, but readability should be on the forefront of things that need to be done right. Yes, there are people that will make it an unreadable mess, but we have code reformat, so if the syntax is verbose enought to be read at a glance, I'm all for it.
+1 as long as syntax gets a hard look at and examples in RFC are amended to show it better :) On Sat, 30 Apr 2016, 09:50 Marco Pivetta, <ocram...@gmail.com> wrote: > 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 > > > > >
