Maps with object keys

Benjamin (Inglor) Gruenbaum inglor at
Mon Feb 17 22:39:24 PST 2014

Thanks, I was starting to feel like I wasn't explaining my issue very well
given the other replies. I'm glad we agree this is not something user-code
should have to shim for language level collections.

I'm working on several projects that perform statistical analysis and I
wanted to stick to JavaScript, this makes it really hard to do so. It
effectively renders `Map`s useless for me exept for readability purposes.
Also, thanks for the straight up 'this is still a problem now' - it
probably saved me a considerable amount of time.

Value types do sound like a better solution than throwing `equals` and
`hash` on every object, it is conceptually similar to the solution I've got
so far (using a flyweight to enforce uniqueness and generate 'value
(Of course the current solution has memory issues which I need to be
careful about - but I hope I'll manage)

I do think there might be a problem with value types (or rather, value
objects) for key though - if I followed correctly, value types do not allow
you to specify `===` and `!==` yourself, they are a recursive structural
equality test which limits your ability to ignore properties you do not
care about. For example, getting points that are unique points on the R2
(x,y plane) by throwing R3 points (x,y,z) into a set with "x,y equality"
and then extracting them. I'm not sure if this was discussed or if it's a
big enough issue but I think it's worth talking about.


On Tue, Feb 18, 2014 at 4:50 AM, Jason Orendorff
<jason.orendorff at>wrote:

> On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum
> <inglor at> wrote:
> > I'm trying to work with ES6 Map objects and I ran into an interesting
> > problem.
> Yes! Well done.
> We've noticed this too, and considered (a) allowing objects to provide
> their own hash and equals operations, as in Java and Python; (b)
> allowing the Map user to specify hash and equals operations for the
> Map at construction time. These were rejected partly because both
> ideas would make Map behavior observably nondeterministic, or else
> overspecify. Also because object hash codes would be exposed to users,
> and ensuring that those do not leak any information about object
> addresses would likely make them slow.
> The solution that prevailed is (c) introduce value types in ES7. With
> value types, you'll be able to declare an aggregate value type, much
> like a Python namedtuple, to use as your Map key. Values of that type
> can be compared for equality with ===, like Python tuples, and Map
> will work accordingly.
> Until value types are spec'd and implemented, the other workarounds
> already mentioned in this thread will have to do, I'm afraid.
> -j
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list