Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.44 as permitted sender)
MIME-Version: 1.0
Sender: dmgx.michael@gmail.com
Date: Mon, 11 Jul 2016 11:15:43 -0400
Message-ID: <CAGovj_Nk9pWrs_KxxZUgkae614=r_yrOfGWHJxf3YCMeSy5zbA@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11372fe447aed705375da039
Subject: [PHP-DEV] Cascade Operator (was Re: [PHP-DEV] Proposal for php7 class
 method return)
From: tendoaki@gmail.com (Michael Morris)

--001a11372fe447aed705375da039
Content-Type: text/plain; charset=UTF-8

On Sun, Jul 10, 2016 at 6:34 AM, Rasmus Schultz <rasmus@mindplay.dk> wrote:

>
> What you're really trying to accomplish is something like the ".."
> operator found in some other languages - this is known as the "cascade
> operator" in Dart, for example:
>
>
> http://news.dartlang.org/2012/02/method-cascades-in-dart-posted-by-gilad.html
>
> There are several problems with method-chaining - the biggest problem,
> as demonstrated by the cascade operator, is that this doesn't need to
> be a problem you solve for every class; it can be done systemically
> with a cascade operator, e.g. supported for every class, not just
> those where you weave in this requirement. Also, method chaining is
> inferior to a cascade operator, which would work not only for methods,
> but for properties as well. More over, a cascade operator would work
> for all existing libraries, whether the designer thought about
> cascading use of various features or not.
>
> In short, this shouldn't and doesn't need to be a problem every
> developer solves for each and every library - we can solve it for the
> language instead.
>
> In other words, it seems you're trying to address a problem that
> shouldn't exist in the first place, so that you can solve a recurring
> problem you should not have to solve at all.
>
> I would be much more interested in seeing a proposal for a cascade
> operator, which, in my opinion, addresses the real problem currently
> driving developers to use method-chaining - I can only view that as an
> unfortunate work-around.
>
> In my opinion, a cascade operator would move the language forward,
> while the addition of a magical type-hint acting as sugar for "return
> $this" merely solves a superficial problem - and propagates a bad
> practice.
>
>
This is a fascinating concept. There's a small gap to this implementation
which I think can be improved on, but still fascinating.

So we currently have -> for invocation of a method on an object.

$a->setSomething('here')->setSomethingElse('there');

But for that to currently work setSomething must return $this.  A cascade
operator would avoid this.  What about =>  ?

$a->setSomething('here')=>setSomethingElse('there');


This alone is pretty cool, but what if you have a method that returns
something you want to use as argument?  The old prototype.js library.
Consider the following

class A {
  public function add( $a, $b) {
    return $a + b;
  }

  public function subtract( $a, $b) {
    return $a - $b;
  }
}

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.

As can be seen above, I'm unsure of what the static method syntax should be.

--001a11372fe447aed705375da039--