Proposal for php7 class method return

Hey Daniel,

I've been playing around with self for a while (mostly dealing with
code-generators and inheritance), and what I found is that it doesn't
really make sense as a type-hint, not even in interfaces.

Besides the type-work to be done to do function setValue($value) : myClass, what is the advantage of having self?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

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

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.

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