There is _always_ a better alternative to mutating arguments in a function.
To me it seems weird to be so puristic about a simple reduce-function, which by-design leads you to mutate the accumulator. I mean for object-accumulators it definitely is just a massive waste to not to just mutate the argument directly without copying. Although as a disclaimer I have to say I am big fan of simple code, were it FP or not. So if you have a messy reduce-function I guess having it immutable makes it a somewhat easier to manage.
"Unobservable" or local mutation is completely fine (and pretty common in most functional programs that get to any significant scale)
I know what happens by reading the function. Pretty much any function that calls a method on some object mutates its argument. It makes little difference if you abstract this mutation behind the method, or do it directly, or do it via a helper function that takes the object as an argument.
> There is _always_ a better alternative to mutating arguments in a function.
No. Most of those are usually more wasteful, because if you can't mutate objects, you'll have to throw them away at every mutation.
Pretty much all issues I ever had with mutation was when object was shared between multiple users, and some users were incorrectly muttating it during some operation that was meant to be temporary.
For example you store params for a AJAX call in some object and for some AJAX calls you just want to modify one of the params for some AJAX call and instead of {...params, prop: 'newval'} you just do params.newval.
But that is a mistake you do a few times, and then learn to recognize when you're doing temporary changes to use copies of objects. Anyway, it is harmful to avoid mutation at all costs.
Are we talking about functions in general, or small accumulator functions here? I would argue that mutating arguments in general is a really bad pattern that certainly will lead to weird and subtle bugs in the long run. It is also completely unnecessary – you have inputs and outputs for a reason. You might know what happens if you read the function yourself, but you can never assume that everyone else will.
> No. Most of those are usually more wasteful, because if you can't mutate objects, you'll have to throw them away at every mutation.
No, you don’t. This is an implementation detail. Libraries like immutable.js [1] (and several others, I believe) makes it possible to work with immutable data structures without cloning anything.
> Anyway, it is harmful to avoid mutation at all costs.
We can more or less agree on this one :) My comment was unnecessary bastant. I have used mutations in reducer aggregators myself. But, avoiding mutation removes a source of bugs, without sacrificing readability or functionality.
What leads you to this dogma?
Why is mutation of a tightly scoped local variable bad?
The initial accumulator of a reducer usually does not exist until the reducer is invoked, or is defined as an arg to the reducer.
What possible harm could result from mutating it in a tight loop until it is returned?
This is not to say that mutation is fine in all circumstances. That's crazy. There are tradeoffs.
But to declare an entire technique off limits, what are your reasons? You seem to assume your own conclusion.
Documentation, good API design. Real-world example of a function I call pretty often (which I’m also interested in knowing your better alternative to):
const extend = (dest, from) => {
for (const x of from) {
dest.push(x);
}
};
(Non-stack-overflowing version of dest.push(...x), by the way.)
It’s probably a good idea to start considering this kind of copying an antipattern. The good news is that the correct implementation doesn’t have to involve mutating any arguments, just a local with unambiguous ownership:
const keyBy = (iterable, key) => {
const map = new Map();
for (const value of iterable) {
map.set(key(value), value);
}
return map;
};
const peopleObj = keyBy(peopleArr, person => person.username);
const keyBy = (array, key) =>
new Map(
array.map(value => [key(value), value])
);Not just created, but properties are being populated one by one.
"can be garbage collected"
And what do you think is computational complexity of garbage collector?
Yes, memory allocation in JS (GCable environment) is cheap. But garbage collection per se is not, it is at least O(N) complex.
Also, why would the memory complexity be n * n? Sure, a new object is created in each iteration, but its not like you have to keep the previous ones in memory - all but the last one can be garbage collected.