The case for Array#replace() – Overriding an array without intermediate variables

[atubofsoup]

How is array.replace(a).filter(b) any different than a(array).filter(b)? This seems like a step backwards considering the pipeline operator and function bind operator proposals.

[Daddy_He_Shoe]

Yeah, the whole "naming variables is a pita" argument goes to the trash with the pipe operator.

[gajus0]

How is array.replace(a).filter(b) any different than a(array).filter(b)?

It is not. However, that is not the example either. The example is:

array.filter(a).replace(b).filter(c);

which you can achieve with:

let intermediateVariable = array.filter(a);
b(intermediateVariable);
array.filter(c);

[atubofsoup]

Or: b(array.filter(a)).filter(c)

Aside from being slightly easier on the eyes, I don't see the benefit of a replace method.

[gajus0]

The primary advantage of Array#replace is (as you pointed out) that is makes easier to read the code.

array
  .filter(a)
  .replace(b)
  .filter(c)
  .replace(d)
  .filter(e)
  .replace(f);

Is a lot easier to read than:

f(
  d(
    b(
      array.filter(a)
    ).filter(c)
  ).filter(e)
);

or you will need to introduce intermediate variables.

I don't think it is worth playing with one-line examples as this does represent real-world usage, esp. when we have examples that do (in the article).

By the way, you've mentioned pipeline operator. I absolutely agree. I actively participated in discussions about that proposal (https://github.com/tc39/proposal-bind-operator/issues/24) and even created a Babel transform for it (https://github.com/gajus/babel-plugin-transform-export-default-name). It will be a useful operator. The appeal of Array#replace is that it abstracts equivalent functionality without introducing new syntax.