Re: [heycam/webidl] record with arbitrary value types as keys? (#509)

More context:

We have a dictionary and we want it to contain a member that is a key-value mapping. We don't want the key-value mapping to be another dictionary type, because then we have to define a new dictionary type. Meaning we have do list all _possible_ keys as members - in the case of enum: list all the enum values as members in the dictionary, in the case of integers: list every possible integer as a string?

For key-value mappings, it seems to me the alternatives at our disposal are `record<K,V>` and `Maplike<K,V>`. I mentioned `Maplike<K,V>` to discuss why we don't want to use the alternative. My assumption was that a dictionary must only contain value types (because they are copied by value), so anything that is an interface like `Maplike<K,V>` is not allowed (because they are copied by reference). Is this correct, or can a dictionary contain a reference type?

> As IDL maps between JavaScript and an internal representation, you cannot really say that K can be something else if that cannot be represented in JavaScript...

Sorry for being unclear. I was thinking the record's getters/setters could be defined with methods in addition to plain ol' properties. So a `record<K,V>` could be "JavaScript object _or_ native backed up object with get(K), set(K,V) methods", allowing any K or V.

But that is confusing...
On second thought I don't think we have to go there.

**Proposal**

Number properties in JavaScript are automatically converted to strings, e.g. `let obj = { 123: 'hello' }` is equivalent to `let obj = { '123': 'hello' }`. Accessed as `obj['123']` or `obj[123]` interchangeably.
`K` should be extended to include numerical values and enums. This does not break the assumption about JavaScript objects.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/heycam/webidl/issues/509#issuecomment-356675109