Re: [heycam/webidl] Specify open dictionaries. (#180)

I think we should leave this Map business for a separate follow-up. In general I think using `sequence<sequence<>>` is the way to do that, maybe with some IDL-provided machinery for converting it into an IDL type or something.

> One more thing worth thinking about: a how would a JS library implement this sort of object? Probably via for-in (hence considering proto props) , or via Object.getOwnPropertyNames. Would it check for enumerability in the latter case?

(/cc @wycats since this touches on things he's had opinions on in recent TC39. For context, we are discussing a new "open dictionary" type to be used for things like HTTP headers, and trying to figure out how to enumerate its properties.)

I think old JS libraries would use for-in; old libraries that followed advice in certain books would use for-in + a hasOwnProperty guard; new ones would use `Object.keys` or `Object.assign`. Future ones might use `{ ...objectSpread }` (see [stage 3 proposal](https://github.com/sebmarkbage/ecmascript-rest-spread)).

In general TC39 has recognized this issue and settled on "own enumerable" as the protocol for these sorts of "record" types. We had a pretty extensive discussion at last week's TC39 about a very related problem when trying to decide the semantics of object spread. We framed it as "records vs. classes". Object spread is designed specifically around the "record" use case, and previous decisions (Object.keys/values/entries, Object.assign, probably some more I am forgetting) have settled on "own enumerable" as the way of determining the keys when using objects as records.

Trying to use class instances as "records" falls down pretty hard, throughout the language, due to this decision. The example we discussed last week was refactoring from `{ x, y }` to an instance of `class Point { get x() { ... } get y() { ... } }`; the refactoring will destroy the value's "recordness". Our conclusion was "that's sad, but it's what we've got for now", plus speculative talk of in the future providing a specific opt-in "record fields protocol" so that classes could bridge the gap and "become" records by declaring how to convert themselves to a record. Then various parts of the language might start automatically respecting that protocol.

In the end there's always going to be a fundamental mismatch between this own-enumerable design and the fact that the natural property access in JavaScript, of `obj.prop`, will consult non-enumerable and non-own properties. I don't think there's much to do there. But I do agree with @jyasskin's intuition that this mostly matters in obfuscated JavaScript contests. The 95% case of `myAPI({ prop1: val1, prop2: val2 })` is not affected.

So in conclusion, I am in favor of sticking with enumerable-own for open dictionaries too.

-- 
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/pull/180#issuecomment-251669022