Hi! > You lack imagination. Here's three to get you started: > > Elixir: > http://elixir-lang.org/getting-started/enumerables-and-streams.html#the-pipe-operator > F#: https://msdn.microsoft.com/en-us/library/dd233229.aspx#Anchor_11 > Clojure: https://clojuredocs.org/clojure.core/-%3E > > And if they seem to obscure, how about this proposal for Javascript? > https://github.com/mindeavor/es-pipeline-operator
Thanks, now I know where it comes from. This would be useful to mention in the RFC. Note the interesting difference - none of them has $$. This construct seems to be much more natural in functional languages (which all of the above are) due to the fact that functions there are more designed for combining, currying, being composed, operated on, etc. > $foo->bar() calls the bar() method invisibly passing $foo as its Explicitly calling method bar on $foo seems to be strange definition of "invisibly". $this (in all it's forms) is a basic concept of OOP. > $foo |> bar($$) calls the bar() method quite visible passing $foo as > its explicitly non-hidden first argument. Visible passing is bar($foo). We don't need another syntax for it. For |> it's not passing of $foo - it's passing of $$. Which needs to be a) figured out what that magic $$ means (note that none of the languages above have magic variables there) and b) located where the value for magic $$ comes from. > The pipe call is clear and easily traces, the object call requires > understanding OOP. I'll grant that OOP is much more common, and > therefore generally understood by individuals who already know OOP (as > tautologous as that statement is). The problem is that, as I see it, pipe call *doesn't* easily trace, especially with addition of $$. As I mentioned already, this code also would be hard to debug. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
