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 objects'). (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. Thanks, Benjamin On Tue, Feb 18, 2014 at 4:50 AM, Jason Orendorff <[email protected]>wrote: > On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum > <[email protected]> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
