Re: [RFC] Pipe Operator
| From: | Larry Garfield | 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.