Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:92970
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
 <8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
Date: Sat, 30 Apr 2016 08:49:31 +0200
Message-ID: <CADyq6sLYYmf5VyhjhgX3Fw+KmRfzrJN442y8gs6gqrhhzwqLAg@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Sara Golemon <pollita@php.net>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113f21da8b096d0531ae2a83
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: ocramius@gmail.com (Marco Pivetta)

--001a113f21da8b096d0531ae2a83
Content-Type: text/plain; charset=UTF-8

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 <smalyshev@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
> smalyshev@gmail.com
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001a113f21da8b096d0531ae2a83--