Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93383
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: softfail (pb1.pair.com: domain golemon.com does not designate 209.85.223.194 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <66d7fe0f-6c0b-c6c0-f30a-a54ccd10e949@gmail.com>
References: <CAESVnVpa5j=fagr-wm5+DzKKX=wzTN1p8+Kv3-KtGpuyH51b0A@mail.gmail.com>
	<CAF1yvARCKbLx6QCFnHNzzMSJhGk_vr7kdi1Uook1Z=xKhJhu_w@mail.gmail.com>
	<66d7fe0f-6c0b-c6c0-f30a-a54ccd10e949@gmail.com>
Date: Tue, 17 May 2016 10:46:38 -0700
Message-ID: <CAESVnVpWJ7d-Y62Lsy1Bx6WrBP7mhvd1C9VvYCoZfdUC59vP0Q@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC] Pipe Operator
From: pollita@php.net (Sara Golemon)

On Tue, May 17, 2016 at 4:14 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 17/05/2016 11:55, Jesse Schalken wrote:
> $id
>     |> StringList::decode($$)
>     |> array_replace($$, $replace)
>     |> StringList::encode($$)
>     |> $id;
>
>
> Sara, what do you think of this tweak, and my subsequent suggestion that the
> pipe should only be usable as a *statement*, not an *expression*?
>
I'm not strictly against it, but I'm not a huge fan.  Primarily, it's
the statement-only restriction that bothers me since (apart from
control flow structures), most constructs in PHP are expressions, not
statements, and this feature naturally fits in the composable
expressions category, not the top-level statement category.  From an
implementation standpoint, I'm fairly confident that the patch would
be much more complex as a result of enforcing that statement-only
requirement.

Meanwhile, if we remove the statement-only requirement, then using
"simple-variable" as a signal to switch to expression termination,
then we introduce a whole class of bug where a user fat-fingers the $$
token in what SHOULD be another link in a chain expression, but it's
not detectable as an error because a simple-var is valid.

And one more counter-example:

$x
  |> foo($$)
  |> $y[$$];

This is no longer a simple var, should that terminate our statement by
writing to $y[$$]? Or should that be seen as the next link in a chain
where we read the value from $y[$$] (which could well have getter side
effects)?  I would probably expect the latter, but maybe the former
was intended?

So yeah, I'm really not a fan.  That said, if enough other people
chime in that they think these issues are surmountable in "a PHP way",
then I'll take a crack at a PR and we can include it in the
discussion, but as-is.... I can't quite get behind it.

-Sara