Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:94459
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 209.85.213.45 cause and error)
MIME-Version: 1.0
In-Reply-To: <CADBV+ZBOTQvSDVvYh6if-wjTGE=pZ9878vvZrD9CoJHuqJwoow@mail.gmail.com>
References: <CADBV+ZBOTQvSDVvYh6if-wjTGE=pZ9878vvZrD9CoJHuqJwoow@mail.gmail.com>
Date: Sun, 10 Jul 2016 12:34:35 +0200
Message-ID: <CADqTB_gOvO10uEr1-uMuHChcRpHmSip1jzE5WN6uReB8yM+VuQ@mail.gmail.com>
To: Daniel Ciochiu <daniel@ciochiu.ro>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Proposal for php7 class method return
From: rasmus@mindplay.dk (Rasmus Schultz)

Just my opinion, but I view method chaining as a poor man's
work-around to a missing (and much more versatile) language feature,
and would therefore rather not see us adding a feature that inspires
what is, in my opinion, and anti-pattern.

Functions are intended as a means of returning the result of an
operation - when you return the object itself, that's not the result
of an operation, so this is highly non-idiomatic use of a very
fundamental language feature, and it clouds the role of functions and
return-values.

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.


On Sat, Jul 9, 2016 at 8:47 AM, Daniel Ciochiu <daniel@ciochiu.ro> wrote:
> Hi,
>
> I have a proposal that for a given method with a return type of <self>, if
> method does not return anything than it should it's instance. It will
> reduce code by only one line, but will improve consecutive method calls.
>
> class myClass
> {
>     protected $value;
>
>     function setValue($value) : self
>     {
>         $this->value = $value;
>     }
>
>     function doubleValue() : self
>     {
>         $this->value*=2;
>     }
>
>     function getValue() : self
>     {
>         return $this->value;
>     }
> }
>
> $calculator = new myClass();
>
> $returnValue = $calculator->setValue(3)
>         ->doubleValue()
>         ->getValue();
>
> echo $returnValue;
>
> Any return defined in the methods body would override the return of the
> class instance.
>
> I am looking forward to your reaction.
> Thank you!
>
> DanielCiochiu