On Dec 9, 2014, at 2:51 PM, Jason Orendorff wrote: > On Mon, Dec 8, 2014 at 3:46 PM, Tab Atkins Jr. <[email protected]> wrote: >> On Thu, Dec 4, 2014 at 9:46 PM, Katelyn Gadd <[email protected]> wrote: >>> I'm surprised to hear that JS runtimes don't necessarily have ways to >>> 'hash' a given JS value [...] >> >> JS has maps/sets that take objects natively, hiding any details about >> how a mutable object is tracked/stored as keys or values, so there's >> never been any need for such a thing. > > It's not rare to want a hashmaps with compound keys. In current JS > there's no convenient, efficient way to make such a hash. If value > types are still happening, they might solve that problem. > >> Explicitly exposing hash codes >> is leaking implementation details into the user-facing API. > > This is certainly true and (afaik) the reason we haven't exposed this > kind of feature so far.
A rationale, that made at least some of us on TC39 semi-confortable with not exposing per object hash values is as follows: If you want to assign per object hash values to some groups of objects, then you can use a built-in WeakMap to associate an application defined hash values with objects in the group. This make the actual hash assignment an application responsibility rather than exposing implementation details. It permits an application to assign deterministic and repeatable hash codes. It even allows different subsystems of an application to use different hash coding for the same objects. It assume that the Weakmap lookup that is used to retrieve the hashcode will be fast, either because the implementation internally uses an inverted map or has an internally per object hash value that is used to access Weakmaps. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
