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

I believe this proposed grammar is not LL(1) parseable.  Specifically, `OpenDictionaryType` looks like a textbook example of <https://en.wikipedia.org/wiki/LL_parser#FIRST.2FFIRST_Conflict>.  I'm willing to be proven wrong on this point, of course.  ;)  I think basic refactoring something like this:

    OpenDictionaryType ::
        dictionary < Type OpenDictionaryTypeTail

    OpenDictionaryTypeTail ::
        >
        , Type >

will address that.

That said, I wish we addressed the "first type must be one of these three things" bit in grammar, not prose.  That, though, would cause an irreconcilable FIRST/FIRST conflict, I'm pretty sure.  That part is rather annoying.  I'm open to ideas for how we can have our LL(1) cake and eat our grammar-enforced sanity too.  One obvious way is to make the key type be the second type.  Another obvious way is to use different names for the two things...  Maybe I'm just overthinking this.

Apart from that, I see the following issues:

1. Using `dictionary` here could be somewhat confusing with the totally separate concept of dictionaries, IMO...  We may want to come up with a different name.

2. I'm not sure I follow the "V must be a type allowed for dictionary members." thing: all types are allowed as dictionary members.

3. We need distinguishability information, overload resolution handling, and union conversion handling for this new type.  In practice, it will behave much like "object".

4. Do we want to allow passing null or undefined to mean "empty open dictionary" the way we do for dictionaries?

5. I don't know whether the intent here is to be black-box identical in terms of the enumeration to structured clone step 22 substep 3, but this proposed logic is _not_ black-box identical to that, because it calls MOP operations in a different order.  It also doesn't call the exact same ones; there's no equivalent of the `HasOwnProperty` check from structured clone here, because the different ordering, which interleaves the `[[GetOwnProperty]]` and `[[Get]]`, calls makes it less important to do that.  For what it's worth, what Gecko implements for MozMap matches neither of these algorithms; I think we do structured clone step 22 substep 3, but without the extra check in substep 3 subsubstep 1.  We also do our conversion to an IDL value right where structured clone would do the `StructuredClone` recursive call.

6. "Repeat, for each element [key, value] of entries" is a bit confusing, because each element of entries is an ES Array.  This needs to spec how to get the key and value out of the array (probably via `Get()` calls, not the destructuring that the current language is so suggestive of).  Alternately, taking a more structured clone like approach makes this not be an issue, of course.

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