Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93020
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain basereality.com from 209.85.161.174 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADyq6sLYYmf5VyhjhgX3Fw+KmRfzrJN442y8gs6gqrhhzwqLAg@mail.gmail.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
	<8ea990da-1fe7-256c-4e08-0b30715c8e8a@gmail.com>
	<CADyq6sLYYmf5VyhjhgX3Fw+KmRfzrJN442y8gs6gqrhhzwqLAg@mail.gmail.com>
Date: Sun, 1 May 2016 15:39:21 +0100
Message-ID: <CA+kxMuQN9Hf4+oFFbf4MOvCYwNzr72mAbOonFtgybbaU0gEhnw@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: danack@basereality.com (Dan Ackroyd)

On 30 April 2016 at 07:49, Marco Pivetta <ocramius@gmail.com> wrote:
> Here's the pseudo-code for a typical request/response dispatch cycle:

Hi Marco,

Could you clarify something for me?

If I submitted a pull-request to you, with variables named like this:

$v = buildRequest();
$v = validate($v);
$v = convertToCommand($v);
$v = execute($v);
$v = convertToViewModel($v);
$v = render($v);
$v = convertToHttpResponse($v);
emit($v);

There is no chance that you would accept it. You would (correctly)
observe that the variables for the intermediate steps have meaningless
names and so the code is hard to reason about. I don't think removing
the presence of the intermediate variables and replacing them with $$
improves this situation.

What is it that having a special pipe operator that make this
acceptable, other than it covers up the lack of names for the
intermediate variables, by using a different syntax?

Marco wrote:
> Relevant: https://youtu.be/UvD1VjRvGIk

I could imagine how having inline branches could be a useful thing for
functional programming, for various scenarios, including being able to
'inline' error handling, to be nearer the source of errors. However
this RFC does not propose that.

cheers
Dan