Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94605
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.214.49 as permitted sender)
MIME-Version: 1.0
Sender: php@golemon.com
In-Reply-To: <5786dd74-8a32-eb16-aec1-77b12d5af1c1@garfieldtech.com>
References: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
 <5786dd74-8a32-eb16-aec1-77b12d5af1c1@garfieldtech.com>
Date: Wed, 20 Jul 2016 21:37:31 -0700
Message-ID: <CAESVnVqxSrkv-E3ofUYwYWU6sjLcMgFbX=tHC5fAN-5bg9Lu_A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: 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 Wed, Jul 20, 2016 at 8:50 PM, Larry Garfield <larry@garfieldtech.com> wrote:
> I am still generally in favor of this proposal.  Especially when dealing
> with nested array functions this operator would be a big boon to
> readability.
>
That's honestly my 90% use-case as well.  array_merge and array_filter
in particular.

> 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. :)


> PS: I am very disappointed that you chose to name the $$ token
> T_PIPE_VARIABLE and not T_BLINGBLING.
>
I leave the silly token names to Ze'ev/Andi (T_PAAMAYIM_NEKUDOTAYIM)
and Davey (T_SPACESHIP).

I am nothing if not entirely serious and professional. ;p

-Sara

P.S. - I'm totes going to make that a secondary voting choice now.
Name the token, 50% majority wins.