Re: [RFC] Pipe Operator

From: Date: Wed, 11 May 2016 23:19:55 +0000
Subject: Re: [RFC] Pipe Operator
References: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17  Groups: php.internals 
Request: Send a blank email to internals+get-93255@lists.php.net to get a copy of this message
On Mon, May 9, 2016, at 10:21 PM, Stanislav Malyshev wrote: > Hi! > > > |> seems like a common symbol to use, but it admittedly does look a > > So, usage in one semi-obscure language (F#) and one completely obscure > one (Elixir) - Clojure doesn't use |> - and one proposal for Javascript > now qualifies for "common". And that counting the fact that neither of > them actually uses the worst part of proposed syntax - magic variable $$. > -- > Stas Malyshev > smalyshev@gmail.com If the issue is $$ feels too Perl like, what is the alternative? Is there another way to chain methods cleanly? In a sense, what we're really talking about here is continuations. Continuations (over-simplified) are a clean way of setting up "run this function, pass its result to this function, pass its result to this function, etc." That makes composition really easy. |> is essentially a continuation syntax. The $$ is to work around the fact that PHP function can have an arbitrary number of parameters, whereas continuations work best with single-parameter functions. Of course, with currying any multi-parameter function can be reduced to 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. Would that limitation help or hinder? 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.

« previous php.internals (#93255) next »