Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94613
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.50 as permitted sender)
To: internals@lists.php.net
References: <CAESVnVoBrtfWGF-Be+uXWwLNO3=JzuLBXyhW0Dpo-NvoskofQw@mail.gmail.com>
 <5786dd74-8a32-eb16-aec1-77b12d5af1c1@garfieldtech.com>
 <CAEsg9X1F1Dfo_7FGgDHhGxA1ypsUE1qEbMkezTOVtJvgY+RcJA@mail.gmail.com>
Message-ID: <597235c0-ebf5-d6b7-4c33-995a45f649a7@gmail.com>
Date: Thu, 21 Jul 2016 14:34:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAEsg9X1F1Dfo_7FGgDHhGxA1ypsUE1qEbMkezTOVtJvgY+RcJA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Pipe Operator v2
From: rowan.collins@gmail.com (Rowan Collins)

On 21/07/2016 13:39, David Rodrigues wrote:
> This is a great idea in general, but I think that this kind of
> operator is not the ideal (expect for $$ that seems very good).
>
> Some possibilities to think about:
>
> |> (as suggested) seems strange and not very clear, mainly in linear calls
[...]
> Should be think about the linear readability too, for instance:
> $object->a()->b()->c() vs. $object|>a()|>b()|>c().

I think it's quite clear, personally, particularly if you just add a bit 
of whitespace:

$thing |> a($$) |> b($$) |> c($$)

The |> looks kind of like a triangle pointing to the next pipe.



> It can works to avoid matroska (as initial suggestion) but for objects too.
> PHP should identify if this operator is used over object or other type
> (that allows the use of $$).
> The problem is it can be confused: are you executing an object method
> or another function with the object?
> Like in: $clockObject |> setHour(12) |> is_string($$). 'is_string' is
> from Clock or PHP native function?

I think you may be confusing this with the other, somewhat 
complementary, proposal of a "method cascade" operator. Since this 
operator always takes the result of one expression as the input to the 
next, the equivalent for object methods already exists: ->

Your example wouldn't do anything much, because there's no $$ in 
setHour(12), but:

$clockObject -> setHour(12) |> is_string($$)

would be equivalent to:

is_string( $clockObject -> setHour(12) )


That said, if there's a possibility we'll have both features, we need to 
think about how the operators will look next to each other, and how easy 
it will be to pick the right one.

Regards,
-- 
Rowan Collins
[IMSoP]