Discuss
  • Value Types as map keys in ES7

Value Types as map keys in ES7

# Benjamin (Inglor) Gruenbaum (11 years ago)

I'd like to raise an issue with ES7 value objects with maps raised here:

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.

# K. Gadd (11 years ago)

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.

# Rick Waldron (11 years ago)

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:

strawman:encapsulated_hashcodes

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: rwaldron/tc39-notes/blob/master/es6/2013-01/jan-29.md#43

# Allen Wirfs-Brock (11 years ago)

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.