On Sun, Jul 10, 2016 at 6:34 AM, Rasmus Schultz <ras...@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.
