Value Types as map keys in ES7
Allen Wirfs-Brock
allen at wirfs-brock.com
Sun Apr 6 17:05:46 PDT 2014
An there is nothing stopping someone from defining their own map class (possibly by subclassing Map) that has its own hashing and comparison policies. JS implementations + ES6 functionality are good enough that we don't have to wait for such things to be built-in.
Allen
On Apr 6, 2014, at 3:51 PM, Rick Waldron wrote:
>
>
> On Sunday, April 6, 2014, K. Gadd <kg at luminance.org> wrote:
> I guess the analog for this in traditional JS 'Object' instances is
> that when you use the [] operator, i.e. obj[valueObject], it actually
> does obj[valueObject.toString()], so you can control the 'hashing
> function' in a sense by overriding toString. It seems natural to want
> something equivalent here, preferably not based on strings... (though
> I don't know how people feel about exposing hash internals and saying
> 'your hash key needs to be an integer')
>
> Map would certainly be far more useful if it had support for
> customizable hashing,
>
> Existing hash code related work:
>
> http://wiki.ecmascript.org/doku.php?id=strawman:encapsulated_hashcodes
>
> http://wiki.ecmascript.org/doku.php?id=proposals:hashcodes
>
> There was also discussion when parameterization of the Map and Set comparator was first added, but custom comparator functions were deferred until some time in which object hash codes are available: https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-01/jan-29.md#43-parameterize-the-equivalence-operator-for-mapset
>
> Rick
>
>
>
> otherwise it's just a slightly faster
> replacement for Objects with cleaner semantics. Maybe making it
> possible to get the same value back using two different keys that
> don't compare the same with === is against the purposes here, though.
>
> On Sat, Apr 5, 2014 at 10:21 PM, Benjamin (Inglor) Gruenbaum
> <inglor at gmail.com> wrote:
> > I'd like to raise an issue with ES7 value objects with maps raised here:
> >
> > http://esdiscuss.org/topic/maps-with-object-keys
> >
> > To save you all time, let me sum things up:
> >
> > ES6 maps don't solve a particular (but common) issue for me - using compound
> > objects as keys. I do a lot of statistical analysis and I need keys to be
> > compound tuples or other values. This is currently not possible with ES6
> > since map key equality is checked with `===` so it is always reference
> > equality
> >
> > ES7 introduces value objects - which are really cool anyway. This allows for
> > compound keys.which partially solves my issue because value keys are
> > compared structurally with `===`.
> >
> > However, it does not let me index on partial information (described in my
> > last commend on that issues). Since it is impossible to override `===` in
> > value objects from what I understand - It would be impossible for me to use
> > partial objects as keys.
> >
> > To illustrate, if for example I have a lot of 10 dim vectors, and I want to
> > index them as keys based on their first two dimensions - it is impossible at
> > the moment and I have to project them into their 2d counterparts which have
> > no further use for me.
> >
> > Is this somehow addressed? I'm unsure where to look for answers. It seems
> > natural to me to allow specifying a hashing function in the `Map`
> > constructor (rather than on every type) to solve this particular (but again,
> > rather common in code that does crunching) problem.
> >
> > Thanks,
> > Benjamin
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140406/558a16fd/attachment.html>
More information about the es-discuss
mailing list