Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94643
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.46 cause and error)
MIME-Version: 1.0
In-Reply-To: <1469202871.3732759.673953873.7108115D@webmail.messagingengine.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>
Date: Sat, 23 Jul 2016 13:15:31 +0200
Message-ID: <CADqTB_i2iaw0ZLi5jW0qwC7KNep_Cv4vTvDU4d_7GTAJp8Z19w@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c12324c60a2dd05384babb7
Subject: Re: [PHP-DEV] Pipe Operator v2
From: rasmus@mindplay.dk (Rasmus Schultz)

--94eb2c12324c60a2dd05384babb7
Content-Type: text/plain; charset=UTF-8

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.

Are most PHP developers going to understand this feature, the meaning of
$$, and when/how to use this?

Are they going to be able to read code written in this way?

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.)

How does this feature compare with the cascade operator more commonly found
in other languages?

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 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...

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.

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.

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.

Just my two cents.


On Fri, Jul 22, 2016 at 5:54 PM, Larry Garfield <larry@garfieldtech.com>
wrote:

> On Wed, Jul 20, 2016, at 11:37 PM, Sara Golemon wrote:
>
> > > However, the introduction discusses fluent chained methods of objects,
> and
> > > states " This RFC aims to improve code readability by bringing fluent
> > > expressions to functional and OOP libraries not originally designed
> for the
> > > task."  The examples, however, all seem to be centered around
> procedural
> > > calls.  (A static method call is the same thing as a procedural
> function
> > > call in this respect.)  When dealing with methods on an object, it
> seems it
> > > wouldn't offer much.
> > >
> > In this context, I'd argue instance method calls aren't much different
> > from static method calls either, but I wanted to avoid too many
> > abstract/contrived examples.
> >
> > I suppose one might do something like:
> >
> >  return $this->loadConfig()
> >     |> $arg->useConfig($$)
> >     |> $this->loadUser($$)
> >     |> array_merge($$, $this->userDefaults);
> >
> > But the PSR7 example is already contrived as it is.
> >
> > > This other recent discussion/proposal for a "Cascade" operator seems
> like it
> > > would handle the OOP/method case much better:
> > >
> > > http://news.php.net/php.internals/94466
> > >
> > > Note: I am not suggesting one is a substitute for the other; rather,
> that
> > > they are complementary by addressing different parts of the problem
> space,
> > > and the Pipe RFC should likely not emphasize OOP usage potential as I
> see
> > > not a great deal there.  I am still in favor of it, but let's not
> over-state
> > > its use cases.
> > >
> > Fair enough.  They certainly complement one another and I wouldn't
> > argue either is a one-job-fits-all solution.  I wasn't trying to
> > emphasize OOP usage so much as include it as applicable.  I think we
> > might actually be agreeing in principle even if we're diverging in our
> > word choices. :)
>
> I agree.  I'm entirely on board with the feature; more just critiquing
> the RFC intro text, which mentions OOP fluency as a use case, which I
> think is an over-reach.  It's a useful enough feature even without
> talking about that, and it seems we agree that the syntax when used with
> methods is a bit awkward.
>
> > P.S. - I'm totes going to make that a secondary voting choice now.
> > Name the token, 50% majority wins.
>
> :-)
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--94eb2c12324c60a2dd05384babb7--