On 11/07/2016 21:17, Marco Pivetta wrote:
On 11 July 2016 at 22:15, Rowan Collins <rowan.coll...@gmail.com
<mailto:rowan.coll...@gmail.com>> wrote:
Again, it's just different syntax for doing things we can already do.
Spot on! Plus it's something arguably considered a bad idea. I don't
think that adding language features for this sort of thing is useful.
Maybe it's even just harmful.
Looking through the reasons given in your blog post, most of them don't
really apply with a dedicated operator, because they're about the
*contract*, and a cascade operator is only useful when the contract is
to return something *other* than the current object.
Specifically, it relies on the assumption that the method is not
returning a new instance. To adapt one of your examples:
$counter->count();
$counter->count();
$counter->count();
$counter->count();
echo $counter->getCount();
// This relies on count() mutating the current object, probably the
contract is to return void
The same thing, with ->> as a cascade operator:
echo $counter
->>count()
->>count()
->>count()
->>count()
->getCount();
Or perhaps for clarity, pull the echo separately:
$counter
->>count()
->>count()
->>count()
->>count();
echo $counter->getCount();
The cascade operator is a tool to use *instead of* a fluent interface,
not *with* it, and it solves a lot of the problems you outlined -
$counter here can be mocked, wrapped, substituted for different
implementations, etc, because the ->> operator makes no more assumptions
than the code was already making.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
