Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94470
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: <CADyq6sKHntBWQNeuGvn1mT5+J3hW_kMao8wiyK141U9tzNi_yQ@mail.gmail.com>
References: <CAGovj_Nk9pWrs_KxxZUgkae614=r_yrOfGWHJxf3YCMeSy5zbA@mail.gmail.com>
 <86455a1e-eb57-1f30-9016-ac70c9f30bdd@gmail.com> <CADyq6sKHntBWQNeuGvn1mT5+J3hW_kMao8wiyK141U9tzNi_yQ@mail.gmail.com>
Date: Mon, 11 Jul 2016 18:30:02 +0200
Message-ID: <CADqTB_gmbKa7YLJer_9jd1X9quZwVZ8dhxpsx_czJB0Nka_FtA@mail.gmail.com>
To: Marco Pivetta <ocramius@gmail.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7
 class method return)
From: rasmus@mindplay.dk (Rasmus Schultz)

> what's the actual added value of this sort of operator?

The only direct value to the language is brevity - mere convenience.

But I think the biggest indirectly added value, is that this will
discourage people from the chainable methods anti-pattern - so this
has value to the community; those who write chainable methods can
stop, and those who want chainable methods can get a wider choice of
libraries that were previously too verbose in use for their taste.

> For this sort of chaining I'd propose, in addition to the cascade operator,
> the chain operator. This would work like the cascade operator except that
> the return of the function is implicitly the first parameter of the next
> argument in the chain

I don't like this idea, at all - I think we should aim for something
consistent with other languages. Per the Dart spec:

> A cascaded method invocation expression of the form e..suffix is equivalent to the expression (t){t.suffix; return t;}(e).

In other words, the expression always evaluates as the object, which
is fine for most cases, e.g. for everything you're doing with
chainable methods today - which can't actually return any values,
since they return $this. Note that something like PSR-7's HTTP
immutable models are actually factory methods, e.g. use-cases not
applicable to the cascade operator.

The other marginal use case perhaps is cases where a builder of some
sort ends with a call to a factory method - this can be done without
adding a second operator, by using parens in a similar fashion to Dart
and others, e.g.:

    $object = ($builder
        ->>setFoo(1)
        ->>setBar(2)
        ->>setBaz(3)
    )->build();

Or obviously:

    $builder
        ->>setFoo(1)
        ->>setBar(2)
        ->>setBaz(3);

    $object = $builder->build();

Regarding syntax - I feel the natural choice, e.g. similar to "." vs
"..", would be a longer arrow --> but that's ambiguous. (decrement
operator, greater than operator)

The proposed |> operator looks horrible and is very awkward to type,
at least on both American and Danish keyboard - I use both. (it reads
like "or greater than" in my mind, so much so that glancing over
Sara's proposal earlier, I didn't even understand what it was.)

Would something like ->> be ambiguous as well? That's fairly close too
- a double-headed arrow, not unlike the double dots of other
languages...


On Mon, Jul 11, 2016 at 5:33 PM, Marco Pivetta <ocramius@gmail.com> wrote:
> Still interested: what's the actual added value of this sort of operator?
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
> On 11 July 2016 at 17:28, Rowan Collins <rowan.collins@gmail.com> wrote:
>
>> On 11/07/2016 16:15, Michael Morris wrote:
>>
>>> But for that to currently work setSomething must return $this.  A cascade
>>> operator would avoid this.  What about =>  ?
>>>
>>> $a->setSomething('here')=>setSomethingElse('there');
>>>
>>
>> This will be ambiguous with array syntax, e.g.
>>
>> $foo = [ $a->foo() => bar() ]
>>
>> could be a call to $a->foo() for the key and to bar() for the value, or
>> just a chain ending with the array value $a->bar().
>>
>> Naming things is hard. Inventing operators is harder. ;)
>>
>> Also note that it's the *first* call that needs a special operator, in
>> order to discard the normal return and substitute the left-hand side,
>> otherwise mixed chains become ambiguous and probably horrible to implement
>> in the engine:
>>
>> $foo->bar()->baz()=>bob() // what is $this inside bob() ?
>>
>>
>>
>> For this sort of chaining I'd propose, in addition to the cascade operator,
>>> the chain operator. This would work like the cascade operator except that
>>> the return of the function is implicitly the first parameter of the next
>>> argument in the chain. Something like this?
>>>
>>> $a->add(1, 2):>subtract(3):>add(4); // return 4.
>>>
>>
>> This exact feature was proposed a couple of months ago by Sara Golemon.
>> See https://wiki.php.net/rfc/pipe-operator and the accompanying
>> discussion http://marc.info/?t=146196088900001&r=4&w=2
>>
>> As far as I know, it's not been formally withdrawn, so might be
>> resurrected in some for for 7.2. It might be interesting to see a cascade
>> operator at the same time, but some of the same concerns that came up in
>> that discussion will probably apply to any proposal.
>>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>