Except it's not a proper key-value data structure, arrays and objects used as keys in one do the lookup via the use of the `==` operator. So it might work, until it doesn't because you got a key in from a different path and then nothing works.
Conversation
I don't think it's reasonable to blame Map for objects implementing equality as reference equality. It would be worse if it deviated from the standard definition of equality in the language. Arrays and objects are what need to be fixed, not Map using `===` (it doesn't use `==`).
1
1
[1, 2, 3] === [1, 2, 3] being false is the real problem. I think they'll eventually end up having old and new style objects exactly like what happened in Python2 since there are so many problems with how operators handle objects and how objects work.
1
1
I think it's entirely reasonable, they just shouldn't have been added in the first place. Just ignoring the old problems and building more on top of the same sandy base is dangerous and probably negligent.
1
They don't need to change Map to fix these problems though. It would be able to work with a new form of arrays and/or operator overloading. Reference equality also wouldn't be the end of the world if it was only a default which could be overridden, like Python3 objects.
1
Map doesn't rule out introducing a way for objects to define equality and a hash function in the future like other languages. The initial implementation didn't need to be tied to other major new features. I think they're doing a great job with the terrible base they were given.
2
Replying to
"doesn't rule out" is a huge cop out too. Literally anything can be justified by that kind of statement.
1
Replying to
How do you think equality should be defined for arbitrary objects by default, if not reference equality? Nice implementations in other languages either allow overriding the implementation and either have no default or default to reference equality.
1
Containers provide custom equality implementations comparing all the members via their equality implementations. JavaScript has no support for this kind of thing and there's no better option available to use than `===`. It would be bad to hard-wire workarounds into Map and Set.
1
You're complaining about one feature being added before a separate feature which works well with it. They haven't done anything that blocks a proper implementation of custom equality and hashing implementations. That's what I was saying which you've misrepresented as a 'cop out'.
1
That's going to be a hard problem for them to solve. Adding Map and Set before solving it didn't make it any harder. The problem exists for every single object type in the language and every library already, for all the operators, including comparison and arithmetic operators.
Replying to
If Map and Set are such a compelling proposition and given how fast the JS ecosystem moves, why have I never seen them exposed from any library that I've used?
1
Replying to
JavaScript libraries are fast adopters on new language features because they need to work in older browsers. How many libraries use the native generator support, which is an incredibly compelling feature?
1
Show replies
Replying to
My big issue is this both Map and Set hide their behaviour behind a documentation comment. Not even TypeScript or Flow can protect you against their shenanigans with their definitions. I wrote an emptySet function that restricts the value type for this reason.
1
Replying to
I don't think it's confusing or at all surprising that the Map and Set types use one of the two implementations of equality in the language. They use `===` rather than `==`. The language doesn't have a standard interface for deeper equality comparisons, which isn't universal.
1
Show replies