Still interested: what's the actual added value of this sort of operator? Marco Pivetta
http://twitter.com/Ocramius http://ocramius.github.com/ On 11 July 2016 at 17:28, Rowan Collins <rowan.coll...@gmail.com> wrote: > On 11/07/2016 16:15, Michael Morris wrote: > >> But for that to currently work setSomething must return $this. A cascade >> operator would avoid this. What about => ? >> >> $a->setSomething('here')=>setSomethingElse('there'); >> > > This will be ambiguous with array syntax, e.g. > > $foo = [ $a->foo() => bar() ] > > could be a call to $a->foo() for the key and to bar() for the value, or > just a chain ending with the array value $a->bar(). > > Naming things is hard. Inventing operators is harder. ;) > > Also note that it's the *first* call that needs a special operator, in > order to discard the normal return and substitute the left-hand side, > otherwise mixed chains become ambiguous and probably horrible to implement > in the engine: > > $foo->bar()->baz()=>bob() // what is $this inside bob() ? > > > > 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. >> > > This exact feature was proposed a couple of months ago by Sara Golemon. > See https://wiki.php.net/rfc/pipe-operator and the accompanying > discussion http://marc.info/?t=146196088900001&r=4&w=2 > > As far as I know, it's not been formally withdrawn, so might be > resurrected in some for for 7.2. It might be interesting to see a cascade > operator at the same time, but some of the same concerns that came up in > that discussion will probably apply to any proposal. > > Regards, > -- > Rowan Collins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
