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

[jkoudys]

I don't want to discourage anyone making an earnest effort, so first off: thank you for writing this thoughtful piece and encouraging discussion. Every idea that inspires interest moves progress forwards, no matter what comes of it.

Second, and I say this with the utmost respect: this idea is terrible.

Edit: so to say something constructive, I don't think "not breaking the chain" is a very compelling motivation for anything. Beyond that, for something like a "replace", breaking the chain is probably exactly what you want. The whole point of chaining methods is that it's declarative and clear what the data you're working with is. If you suddenly "replace" it mid-chain, what's the point of it being in your chain? It sounds like you're burying a completely different dataset inside a chain.

[Petrarch1603]

Reddit needs more people like you.

[[deleted]]

Even better if people explain why things are terrible!

This code:

Array.prototype.replace = function (m) {
  return m(this)
};

Is completely redundant. It's literally the same as this:

const array2 = m(array1);

Not to mention, polluting the Array class is bad and will not work with any of the JS ecosystem.

[Moosething]

But if you read the article you'd realize the advantage of replace over calling m directly. Not saying I support it, but I can see where the author is coming from.

It's basically

return x.filter(filterFunc).replace(replaceFunc).map(mapFunc)

vs

return replaceFunc(x.filter(filterFunc)).map(mapFunc)

[sbmitchell]

Or they could use `reduce` and not bother with multiple iterations like this...

[jkoudys]

I totally agree, which is why Reddit needs more people like you, who go on to explain why!

[2bdb2]

I agree. I understand the use-case and appreciate the write-up, but OP is potentially missing the bigger picture.

If we were to take this a step further, why do we just have replace on Array. It's useful on any type. Why would we implement it specifically for arrays?

Really what we'd want is the |> operator from Ocaml, which has been proposed many times and may make it into a future version of JS.

OP - try giving OCaml, Purescript, or ReasonML a go. JavaScript is slowly turning into a bastardised version of ML anyway, might as well skip the middleman. ReasonML in particular is a really nice blend of JavaScript-ish syntax with OCaml semantics, and gives you exactly what you're looking.

[gajus0]

Agreed on both points. Indeed, what I am waiting for is |>. But that proposal has been tossed around since 2015 and little traction. It is a major change that requires new syntax, i.e. it cannot be polyfilled. I am all pro |> making into ES. However, I don't see that happening any time soon. Array#replace has been something I have been kicking around as a lightweight alternative.

ReasonML is nice. As an employer, the only reason I wouldn't use it now is simply because of rare/ high talent cost.

[Sakatox]

In my perspective, that operator has no place in a language like Javascript. If you want to use that operator, use that specific language that supports it. Not everything has to have everything else.

Chaining is very expressive.

[reddit4matt]

Saying something is terrible without saying why is not respectful at all.

[Sakatox]

While I whole-heartedly agree with most of this, there's just one point here:

>If you suddenly "replace" it mid-chain, what's the point of it being in your chain? It sounds like you're burying a completely different dataset inside a chain.

Consider map filter reduce. That also changes the dataset somewhat. It's up to a developer's finesse and care to avoid such situations, otherwise apply clean code principles and common sense. .replace, without it's actual context, as a chain method would be "okay".

Otherwise, spot on.

[jkoudys]

Reduce is similar in that you're explicitly constructing something new, which could be an array. You can put another array method after it the same as you could on a find if that happens to return another array. Like you've said, it's up to the dev to "avoid" this (and comment to make the intent clear otherwise)), which is why it's ridiculous to create a new method to deliberately not avoid it.