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 <dan...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
