The "Pipeline" Operator - Making multiple function calls look great

Gilbert B Garza gilbertbgarza at gmail.com
Tue Nov 10 20:08:02 UTC 2015


>
> I agree that your proposal wins points for simplicity (both semantic and
> syntactic), but having to create an arrow function to pass more than one
> argument feels a bit awkward and seems to defeat some of the readability
> benefit.


I find it to be pleasant :) It gives opportunity to semantically name your
arrow function parameter, and it also follows the consistency of "the value
on the left gets fed to the function on the right".

But yes, I do agree having partial application somehow built-in would be
nice.


Not to mention it would be pretty slow. That's going to be creating a closure
> each call.


Normally yes, but since the pipeline operator is a pure function, I think
it's possible for the compiler to optimize away the intermediate arrow
functions. I mention this in the "Functions with Multiple Arguments"
section
https://github.com/mindeavor/ES7-pipeline-operator#functions-with-multiple-arguments


On Tue, Nov 10, 2015 at 12:52 PM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> Inline
>
> On Tue, Nov 10, 2015 at 12:52 PM, Kevin Smith <zenparsing at gmail.com>
> wrote:
> >> - I don't like the requirement to use the keyword `this` to compose
> >> functions. JS already has many features to support the keyword `this`:
> >> prototypes, method invocations, function binding, arrow functions, and
> >> probably others. I prefer a feature that assists the other side of the
> >> spectrum.
> >
> >
> > Yep - a well documented critique.  It depends on your point of view, I
> > think.  If you view these things as "extension methods", then using
> `this`
> > makes more sense.
> >
> >> - The fact that there are new semantics to what looks like a normal
> >> function call (e.g. `->map(...)`) doesn't set well with me. You could
> argue
> >> that it's something to get used to. Even in that case, I would expect
> the
> >> first argument I give to `map` to stay the first argument.
> >
> >
> > This is a reasonable objection, I think.
>
> Not to mention it's still a point of contention:
>
> https://github.com/zenparsing/es-function-bind/issues/26#issuecomment-154130932
> (from here, down)
>
> >
> >> With the pipeline operator, partial application is left to the
> developer.
> >> They can choose to use arrow functions, or to curry their functions. I
> think
> >> this is the best option since it keeps things simple (no new
> semantics), and
> >> remains readable – see the "Function with Multiple Arguments" section
> in the
> >> GitHub link https://github.com/mindeavor/ES7-pipeline-operator
> >
> >
> > I agree that your proposal wins points for simplicity (both semantic and
> > syntactic), but having to create an arrow function to pass more than one
> > argument feels a bit awkward and seems to defeat some of the readability
> > benefit.
>
> Not to mention it would be pretty slow. That's going to be creating a
> closure each call. Engines still struggle with making closures fast.
> It's non-trivial at runtime to create a closure that's performant.
>
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> --
> Isiah Meadows
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151110/3efeb0c3/attachment-0001.html>


More information about the es-discuss mailing list