Is this correct for Javascript?
https://github.com/tc39/proposal-change-array-by-copy
This is my opinion about it: This kind of proposal are very harmful for JS/TS.
What will we do? Duplicate every method that could create a new modified Array/Object?
The learning curve got duplicated for mutable methods. Why do we allow this? We need to stop this at its roots now that we have time, before it's too late.
I don't know where could i do propose this, but i have to express myself:
I want to remove those stup*d new methods an create a new one called
.clone() that allows to developers clone the object...GitHub
GitHub - tc39/proposal-change-array-by-copy: Provides additional me...
Provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change. - tc39/proposal-change-array-by-copy
5 Replies
Maybe you could check out the tc39 discourse group
Thanks, i love you
yw :deno_thumbs_up:
from what I see, they decided to go with these so that it is consistent with
Tuple
Tuples are immutable so they won't have a sort() method
The proposal aims to avoid "mutating" an array after creating
If we get a .clone() method, .clone().sort() would duplicate the array and then mutate the new array
proposal wants to make a new one with sorted values directly so that it works with tuples (by duck typing, a tuple would be a supertype of array ig)Thanks for the reply, i actually i'm not sure if i'm wrong
I think that do use of
.clone() to create a new mutable instance is the correct way to handle mutations with Tuples
If not, a better way could be create a new mutable common Array instance of the tuple, using Array.from
If we're talking about performance issues, to avoid the 2 steps (creation/modification) the .clone() method could receive a "mutator". .clone(Array.prototype.reverse) or a enum value .clone(MutationType.Reversed)