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

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?

The other thing I find myself coming back to is what the actual use cases are in practice.  We have `Headers`, which really does have an open-ended list of things.  We have the animation stuff, which really has a fixed set of possible props, but typically sets a few out of hundreds and doesn't want the performance impact of the dictionary processing model.  We have the worklet things, right?

Would typical consumers have basically an object literal here, or an object that comes from "somewhere" or a thing like a Map that they have to adapter into looking like an object for purposes of these APIs?  Would it make any sense to design the API surface such that you can pass in either a Map or a random other object, and then extract values from the passed-in thing via `.entries()` (possibly the initial value) and `Object.entries` respectively?  I guess that would have the drawback that we would no longer be guaranteed key uniqueness and would have to handle repeating keys... but we have to do that anyway if we use [[OwnPropertyKeys]], because nothing enforces that [[OwnPropertyKeys]] returns a list with no repeats in it, as far as I can tell.

-- 
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-251487610