Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94636
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.29 cause and error)
Message-ID: <1469202871.3732759.673953873.7108115D@webmail.messagingengine.com>
To: internals@lists.php.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
In-Reply-To: <CAESVnVqxSrkv-E3ofUYwYWU6sjLcMgFbX=tHC5fAN-5bg9Lu_A@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>
Date: Fri, 22 Jul 2016 10:54:31 -0500
Subject: Re: [PHP-DEV] Pipe Operator v2
From: larry@garfieldtech.com (Larry Garfield)

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