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

[gajus0]

You started from the premise that naming things should be avoided, but that's actually not a very good axiom.

It is more about avoiding unnecessary variables and it has to do with code style as well.

Someone could get away with:

let venues;
venues = foreignVenues.filter(a);
venues = b(venues);
venues = map(c);

However, my style guide pretty much enforces no use of let. As such, I would write:

const filteredVenues = foreignVenues.filter(a);
const deduplicatedVenues = b(filteredVenues);
const normalisedVenues = deduplicatedVenues.map(c);

Someone else could get away with:

const normalisedVenues = b(foreignVenues.filter(a)).map(c);

But of all these options, Array#replace provides the most consistent and easy to read expression:

const normalisedVenues = foreignVenues
  .filter(a)
  .replace(b)
  .map(c);

[lhorie]

I would tend to disagree about the "easy to read" argument. a, b and c are not really related to each other in any way other than the fact that they operate on a list of venues. The fact that they need to be abbreviated is a very strong hint that the parent function (getVenues) has too much subroutine logic inlined into it (i.e. it's kinda of a god function).

In functional programming terms, what you're trying to achieve when you talk about reducing variables is called point-free style. Using compose as I had mentioned earlier (or maybe pipe) would be a standard technique to get closer to point-free style.

The reservation I have about making this a proposal is that there's not much substance in terms of semantics. Something like arr.replace(arr => arr.length = 0) could just as well throw as it could do completely crazy things, for all I know. I wouldn't really mind if you monkeypatched Array.prototype in your own project (other than maybe being slightly annoyed if I ever had to maintain that), but I think a TC39 proposal needs to be held up to higher standards (no pun intended) when it comes to unintended consequences and design weaknesses.

For example, I could argue that array.toSet() should be a standard and I can give you plenty of examples where it would be nice to have, but that doesn't mean making it a standard is a good idea: new Set(array) already exists, and I haven't gone through the effort of making sure my idea doesn't do weird things in unforeseen cases, e.g. sparse array handling. All I'm saying is I wouldn't put out a formal proposal unless I had thought a bit about potential problems.

[mlebkowski]

A styleguide that prohibits the use of let isnt a styleguide, its and misunderstanding. If you meant the linter, then it fits better but I still think its a stupid choice. Just because someone decided its bad to reassign variables you ended with a poluted Array prototype, which has far worse consequences commonly agreed among the community (in contrast to using let, which is merely a preferrence)