Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94472
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CADqTB_gmbKa7YLJer_9jd1X9quZwVZ8dhxpsx_czJB0Nka_FtA@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>
	<CADqTB_gmbKa7YLJer_9jd1X9quZwVZ8dhxpsx_czJB0Nka_FtA@mail.gmail.com>
Date: Mon, 11 Jul 2016 19:55:11 +0200
Message-ID: <CABdc3Wpf=CwY0B_ccMB7eAU20_KWe-W_jDPoaUfyosYJmoXNkA@mail.gmail.com>
To: Rasmus Schultz <rasmus@mindplay.dk>
Cc: PHP Internals List <internals@lists.php.net>, Rowan Collins <rowan.collins@gmail.com>, 
	Marco Pivetta <ocramius@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c06d756965ab305375fda9f
Subject: Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7
 class method return)
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--94eb2c06d756965ab305375fda9f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 nex=
t
> > 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

>
> 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 =3D>  ?
> >>>
> >>> $a->setSomething('here')=3D>setSomethingElse('there');
> >>>
> >>
> >> This will be ambiguous with array syntax, e.g.
> >>
> >> $foo =3D [ $a->foo() =3D> bar() ]
> >>
> >> could be a call to $a->foo() for the key and to bar() for the value, o=
r
> >> 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()=3D>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=3D146196088900001&r=3D4&w=3D2
> >>
> >> 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
> >>
> >>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--94eb2c06d756965ab305375fda9f--