Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
Sender: dmgx.michael@gmail.com
Date: Tue, 12 Jul 2016 09:54:53 -0400
Message-ID: <CAGovj_M0D24snWfeaEs=4aPP3fbdoPDuGwPyGBDw9EqtEnFW3w@mail.gmail.com>
To: =?UTF-8?Q?Micha=C5=82_Brzuchalski?= <michal.brzuchalski@gmail.com>, 
	PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1141ca7c0a5e920537709d2c
Subject: Re: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7
 class method return)
From: tendoaki@gmail.com (Michael Morris)

--001a1141ca7c0a5e920537709d2c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 double
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.

--001a1141ca7c0a5e920537709d2c--