Ok, but they’re already shipped and in the spec - they will never be removed. Your opinion is noted but doesn’t change that fact.
I'm agree with you, we don't need to delete them. We can deprecate them. No one developer will use those methods if are deprecated.
We should try to solve this fast...
The names are common in other languages.
Kotlin has
list.sort() (mutating) docs
list.sorted() (non-mutating) docs
Java has
Arrays.sort(array) (mutating) docs
stream.sorted() (non-mutating) docs
Python has
array.sort() (mutating) docs
sorted(array) (non-mutating) docs
Swift has
collection.sort() (mutating) docs
collection.sorted() (non-mutating) docs
So many languages has the .first(), .last(), .isEmpty() and the usefull .clear() for their arrays, but JS does not. It does not means anything
Js is a universal language used in all browsers and all devices, we can't just copy and paste other bad languages designs (personal perspective, I did argument on this post)
We need to think about what is better to write and understand, avoid stun developers with a lot of redundant methods and give them exactly what they need, this is related with the scalability of all JS projects
We don't deprecate things in the language, and your faith that developers will follow guidance is endearing, but empirically largely false.
1 Like
There's a long-standing convention that .toFoobar() methods returns some representation of the object without modifying it. Such as .toString(), .toUpperCase(), .toURL(), etc.
3 Likes
Could you link to that? I thought lookup was amortized O(1). And monomorphic inline caches reduce that even further to a simple (and easily predicted) conditional jump.
There might be at most about 100 or so externally visible function object types in the entire spec today, with the largest objects (Date, Array, and %TypedArray% prototypes) having less than 20 properties in total. Assuming the growth factor is chosen correctly (normally 0.8), you won't run into the non-linear performance problems in hash tables with any remotely modern form of open addressing until you have thousands of entries on a single object.
So I'm highly skeptical of that.
IIRC: it was when change-array-by-copy tried to add >10 methods all at once. I was surprised at first too. But now I can't remember what I saw it (either an issue, meeting notes, or in another repo when they brought this up as an argument for "no more array methods")
The no-more-array-methods leaning is mostly driven by how often these end up breaking existing websites. It was something like 1 in 3 of most recently added array methods caused websites issues. Array.prototype.group was moved to {Map,Object}.groupBy for this reason. Static methods tend to cause fewer issues.
1 Like