Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94490
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.41 cause and error)
MIME-Version: 1.0
In-Reply-To: <CAGovj_M0D24snWfeaEs=4aPP3fbdoPDuGwPyGBDw9EqtEnFW3w@mail.gmail.com>
References: <CAGovj_M0D24snWfeaEs=4aPP3fbdoPDuGwPyGBDw9EqtEnFW3w@mail.gmail.com>
Date: Tue, 12 Jul 2016 17:25:13 +0200
Message-ID: <CADqTB_jxQE8GEgJq0ddDLqGW49_zb53YEErnenPFnzfeFxFnHQ@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
Cc: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7
 class method return)
From: rasmus@mindplay.dk (Rasmus Schultz)

IMO, static methods have very little need for this feature - you
rarely need to make repeated series of static calls and static
property assignments. Let's not complicate this.


On Tue, Jul 12, 2016 at 3:54 PM, Michael Morris <tendoaki@gmail.com> wrote:
> On Mon, Jul 11, 2016 at 1:55 PM, Micha=C5=82 Brzuchalski <
> michal.brzuchalski@gmail.com> wrote:
>
>> 11 lip 2016 18:31 "Rasmus Schultz" <rasmus@mindplay.dk> napisa=C5=82(a):
>> >
>> > > 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 =3D ($builder
>> >         ->>setFoo(1)
>> >         ->>setBar(2)
>> >         ->>setBaz(3)
>> >     )->build();
>> >
>> > Or obviously:
>> >
>> >     $builder
>> >         ->>setFoo(1)
>> >         ->>setBar(2)
>> >         ->>setBaz(3);
>> >
>> >     $object =3D $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...
>> >
>>
>> IMHO double-headed arrow looks pretty nice and whole idea is great. Very
>> big +1 for this feature
>>
>>
>>
> Agreed, but what about static methods?  Triple colon perhaps?
>
> A::setFoo(1)
>   :::setBar(2)
>   :::setBaz(3);
>
> And I do agree that the double period is cleaner, but the bus left the
> station a very long time ago (PHP 3 at least) by making . the connotation
> operator.  Or at least I think so. If the parser could deal with it doubl=
e
> period would be best because it could apply to both contexts.
>
> $object->setFoo(1)
>   ..setBar(2)
>   ..setBaz(3);
>
> A_Class::setFoo(1)
>   ..setBar(2)
>   ..setBaz(3);
>
> But again, I don't know how feasible the above is since I know next to
> nothing about internals.