Value Types as map keys in ES7

K. Gadd kg at
Sun Apr 6 10:45:28 PDT 2014

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, 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> wrote:
> I'd like to raise an issue with ES7 value objects with maps raised here:
> 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

More information about the es-discuss mailing list