ES7 Proposal: The Pipeline Operator (github.com)

I'm not a believer in the FP vs. OO religion, and have historically been skeptical of the bind operator. That said, I think that both composition via objects and composition via functions have their place.

The pipeline operator attempts to make composition via functions more readable (left-to-right instead of right-to-left) and unless you think composition via functions is a bad idea in JS in all cases, I'm not sure what "full-on functional" has to do with it.

The main goal of all of these proposals is "left to right" composition when working with functions, and functions take parameters.

    function double(str) {
      return str+', '+str;
    }
    function ucase(str) {
      return str.slice(0,1).toUpperCase()+ str.slice(1);
    }
    function exclamation(str) {
      return str+"!";
    }
    
    var _="hello";
    _ = double(_);
    _ = ucase(_);
    // _ = foo(_);
    _ = exclamation(_);
    
    console.log(_); // Hello, hello!
    
    function pipe() {
      var functions=[];
      for(var i=0; i<arguments.length; i++) {
        functions[i]=arguments[i];
      }
      return function pipe_call(arg) {
        for(var i=0; i<functions.length; i++) {
          arg=functions[i](arg);
        }
        return arg;
      }
    }
    
    var _="hello";
    _ =pipe(
      double,
      ucase,
      // foo,
      exclamation
    )(_);
    console.log(_); // Hello, hello!

What happens is much easier to read if you know what the operator means.

The only way the old way has more clarity is in the "we are already familiar with it" way. In any other way, this method trumps it.

exclaim capitalize doubleSay

Sure, some of us has spent 20 years doing this so it's easy, but you can't deny that this is far nicer to read:

doubleSay capitalize exclaim

I'm a big fan of Fluent Interfaces, so I use this construct fairly often:

"hello".doubleSay().capitalize().exclaim()

    _(array)
    .compact()
    .map(function(x) {
       return x * x;
    })
    .filter(function(x) {
        return x > 100;
    }).value()

The problem with this is to be able to add a custom function to this pipeline, you have to extend the prototype of the library with your own functions, or re-implement it.

Extending the prototype is considered bad practice for a lot of reasons, for example due to polluting code in other modules or upstream changes breaking your code.

If instead of chaining methods we chained functions we are left with this awkward syntax:

    custom(filter(map(compact(array), function(x) {
         return x * x;
    }), function(x) {
         return x > 100;
    }));

    compact(arr)
    |> map(function(x) {
        return x * x;
    })
    |> filter(function(x) {
        return x > 100;
    })
    |> custom

Example:

    (defn do-stuff [params-map]
       (->
          (build-object params-map)
          (do-thing-with-object)
          (extract-thing)
          (format-thing)))

    attrs
        |> bounded('age', 1, 100)
        |> format('name', /^[a-z]$/i)
        |> Person.insertIntoDatabase

The main counterargument to "do it like underscore" is that underscore still ends up being an object whose methods are added to a prototype, not imported.

The benefit of the "pipeline" or "bind" approach is that you get left-to-right composition while still importing the names you're using.

Really? have you never seen unix pipes?

  let names = document.querySelectorAll('.entry')
                      .sortBy('title')
                      .filter(entry => entry.getAttribute('data-url') in whitelist)
                      .map(entry => entry.getAttribute('name');

And I want it painted green ;-)

> ... which doesn't have an immediate meaning to my eyes.

It's a matter of background. F#, Julia and Livescript have identical operators, likely among others.

https://msdn.microsoft.com/en-us/library/dd233229.aspx#Ancho...

http://docs.julialang.org/en/release-0.4/stdlib/base/?highli...

http://livescript.net/#piping

    > I bet Lispers would beg to differ. :D

I wrote and read threading macros all the time when I used Clojure. Turns out it cleans up code.

This proposal is about function application.

This syntax can be used anywhere as long as the types signatures of the functions are conducive to the chaining.