On 07/20/2016 07:42 PM, Sara Golemon wrote:
With the branching of 7.1, and after some reflection on the previous
feedback, I'd like to reopen discussion of the Pipe Operator RFC
https://wiki.php.net/rfc/pipe-operator which I had previously put on
hold. I've changed much of the argument wording of the proposal, but
not the substantive feature set. If you still feel it's unworkable,
I'd like to encourage you to respond with what you think would make it
workable (if anything). Thanks.
-Sara
I am still generally in favor of this proposal. Especially when dealing
with nested array functions this operator would be a big boon to
readability.
However, the introduction discusses fluent chained methods of objects,
and states " This RFC aims to improve code readability by bringing
fluent expressions to functional and OOP libraries not originally
designed for the task." The examples, however, all seem to be centered
around procedural calls. (A static method call is the same thing as a
procedural function call in this respect.) When dealing with methods on
an object, it seems it wouldn't offer much.
This other recent discussion/proposal for a "Cascade" operator seems
like it would handle the OOP/method case much better:
http://news.php.net/php.internals/94466
Note: I am not suggesting one is a substitute for the other; rather,
that they are complementary by addressing different parts of the problem
space, and the Pipe RFC should likely not emphasize OOP usage potential
as I see not a great deal there. I am still in favor of it, but let's
not over-state its use cases.
PS: I am very disappointed that you chose to name the $$ token
T_PIPE_VARIABLE and not T_BLINGBLING.
--Larry Garfield
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
