Hi!
> If the issue is $$ feels too Perl like, what is the alternative? Is > there another way to chain methods cleanly? Well, that's a loaded question. It presumes we already agreed on needing to chain methods using special syntax outlined in the RFC - which we didn't - and the only problem is whether it's $$ or $* or @% or some other sequence of symbols. I'm not convinced at all of the premise, so discussing which exactly two characters should be used for $$ does not really appeal to me. > In a sense, what we're really talking about here is continuations. Not sure how it's continuations: https://en.wikipedia.org/wiki/Continuation If anything, generators look like continuations. This just looks like fancy way to write sequence of function calls with novel syntax. Do you mean something else by "continuations"? Or I missed some part of the RFC? > a series of single parameter functions. So what if we were to limit the > concurrency syntax to single-parameter functions? And if you want to > reduce a multi-parameter function to a single parameter function, yay > closures. I'm not sure where "concurrency syntax" comes from. What's concurrent here? > Either way, I firmly believe that more functional-friendly capabilities > like continuations, promises, etc. are a direction that PHP needs to > move, and syntax in that direction is valuable. I'm not sure that's where PHP *needs* to move, but we already have continuations, as I mentioned. As for other async capabilities like promises/futures, that may be possible but there are some hard questions need to be answered here because PHP is not well suited for environment sharing. I also am not sure functional syntax is well suited for PHP, given that PHP is not a functional language and vast majority on PHP code is not written in functional manner. Functional programming requires quite different approach than most PHP applications take, and frankly I'm not sure why this should change - there are enough functional languages around. Of course, that doesn't mean avoiding *all* functional features - some of them make total sense even in non-functional language, like closures or functions like map/reduce/filter. Some, however, are harder to fit. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
