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

Alican Çubukçuoğlu alicancubukcuoglu at
Mon Dec 14 06:10:45 UTC 2015

So these are your example utility functions:
function capitalize (str) { /* ... */ }
function trim (str) { /* ... */ }
function splitBySpaces (str) { /* ... */ }

What makes you think that utility functions should be coded like that? Take
these for an example:
// Using "this"
function trim(characters) {
  // this...
  return capitalizedString;

// Using a parameter
function trim(string, characters) {
  // string...
  return capitalizedString;

What is the best practice when coding functions like this? Using `this` is
a clear winner since that's how the native and user utility methods for the
`.prototype`s of String, Array and such work. More importantly, that's how
polyfills are done. Plus FBS, which allows very easy consumption of
functions coded like this, is already at stage 0.

When the functions in the PO examples should be coded with `this` anyway,
then where is the need for PO?


Also, you shouldn't make your examples this simple. It's almost like you
are deliberately trying to hide the truth.

This is the reality of current PO syntax:
console.log(getSomething() |> _ => trim(_, '-') |> _ => words(_, /[^, ]+/g)
|> _ => pad(_, 20, '-'));

Even if there is a need for PO, the syntax should change:
param1 |> func(param2, param3)

console.log(getSomething() |> trim('-') |> words(/[^, ]+/g) |> pad(20,

Then it becomes something very close to FBS and doesn't look weird when
it's used with it everything else:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list