Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94658
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.170 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <CADqTB_i2iaw0ZLi5jW0qwC7KNep_Cv4vTvDU4d_7GTAJp8Z19w@mail.gmail.com>
References: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
 <5786dd74-8a32-eb16-aec1-77b12d5af1c1@garfieldtech.com> <CAESVnVqxSrkv-E3ofUYwYWU6sjLcMgFbX=tHC5fAN-5bg9Lu_A@mail.gmail.com>
 <1469202871.3732759.673953873.7108115D@webmail.messagingengine.com> <CADqTB_i2iaw0ZLi5jW0qwC7KNep_Cv4vTvDU4d_7GTAJp8Z19w@mail.gmail.com>
Date: Sat, 23 Jul 2016 13:46:18 -0700
Message-ID: <CAESVnVrVQtc9aDFXR9A9XepK+Ekuw-fGat3jo5Z8z-Q6URPo7w@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: Larry Garfield <larry@garfieldtech.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Pipe Operator v2
From: pollita@php.net (Sara Golemon)

On Sat, Jul 23, 2016 at 4:15 AM, Rasmus Schultz <rasmus@mindplay.dk> wrote:
> FWIW, I've read the manual page for the Hack page, and the RFC, a couple of
> times now, and I simply don't understand it.
>
Perhaps the documentation needs clarifying then.

> Are most PHP developers going to understand this feature, the meaning of
> $$, and when/how to use this?
>
Yes.  PHP developers are excellent at Google and StackOverflow.

> Are they going to be able to read code written in this way?
>
Yes.

> To your knowledge, are there any other languages where this feature is
> found, or is it another one of those exotic features currently found in
> Hack and nowhere else? (I know a bunch of languages, and this feature
> doesn't ring any bells.)
>
Elixir, F#, Swift (via library extension), ISTR a few others when I
was researching a few months ago, but can't recall them offhand.

> How does this feature compare with the cascade operator more commonly found
> in other languages?
>
To turn your previous question around, what languages?

I see them complementing one another, serving different goals and
solving different problems.  I suppose you could ask how this compares
with short ternaries, coalesce, or bitwise xor, and the question will
make as much sense.

> I mean, maybe it's just me, because I'm familiar with the cascade operator
> from other languages - but it seems simpler, more intuitive, easier to pick
> up, and appears to solve most of the same problems? If so, perhaps it would
> be right to consider the cascade operator as an alternative to this feature.
>
I would rather consider them both since they solve different problems
in different ways.

> I know that Hack may be closer in nature to PHP than some other languages,
> but if someone is familiar with both, likely they're not coming from Hack
> and moving to PHP, they're likely moving from PHP to Hack, so language
> similarity might not be the best argument for referencing Hack on this
> point, as opposed to referencing other languages...
>
Fair point, I'll add mentioned of the above languages to the RFC.

> It seems to me, the main difference between the pipe operator and a cascade
> operator, is the anonymous context variable $$ created by the pipe operator
> - I think, partially, this is what makes those expression hard to read; the
> context changes (or does it?) along the way, but the (nameless) symbol used
> to reference those objects, in the same expression, are identical.
>
It's also what makes the cascade operator unable to solve all the
problems which the pipe operator is capable of solving.  Cascade
applies to a very narrow band of instance method calls.  Pipe applies
best to static methods and procedural functions (which some
applicability to methods).  The flexibility of being able to place
that lhs element in an arbitrary location is what makes it powerful.

> Rather than writing extremely long expressions, as demonstrated in the RFC,
> I think, personally, if this feature were introduced, I'd lean more on
> intermediary variables, with names, that clarify the meaning - referencing
> a bunch of intermediaries with a nameless variable doesn't help readability
> at all, in my opinion.
>
The RFC states why this may not be a preferred course.  How do we
know, at a glance, that these well named intermediates are/aren't used
later in the scope?  What happens to destructor ordering when the
variable lives till the end of the function? How does this impact
optimization potential?

> In contrast, I have no issue reading expressions with the cascade operator;
> again, maybe that's just because I'm familiar with that operator from other
> languages, but I don't think the nameless $$ variable helps readability or
> understanding.
>
You keep acting as if pipe vs cascade is even a competition.  It's
not.  They're different solutions to different problems which require
different approaches.

-Sara