Dictionary mixins

[annevk]

ExtendableMessageEvent defined at https://w3c.github.io/ServiceWorker/#extendablemessage-event-section and MessageEvent defined at https://html.spec.whatwg.org/multipage/comms.html#messageevent are extremely similar.

To duplicate less and consolidate fixes in a single place it would be better if they used a shared mixin. However, that would not work for initializing them as the dictionaries would still need to have the duplication.

Thus, the need is born for dictionary mixins.

Background: w3c/ServiceWorker#989.

[bzbarsky]

This specific case can't be handled with dictionary inheritance?

The general case of multiple specs all wanting to add stuff to multiple dictionaries can't be handled that way, of course, but the specific cases of "multiple specs wanting to add stuff to a single dictionary" case is handled by partial dictionary and afaict "multiple specs wanting to share a single dictionary definition but extend it" is handled by dictionary inheritance. Unlike interface inheritance, dictionary inheritance has very little in the way of observable properties (nothing apart from [[Get]] ordering), so should be quite usable as a specification device as needed here.

We can probably do full-on dictionary mixins, but I'd like to see a better justification for the resulting complexity, both in terms of spec and in terms of implementations.

[annevk]

The problem with inheritance is that we have Event (EventInit dict) > MessageEvent (MessageEventInit dict) and on the other side we have Event (EventInit dict) > ExtendableEvent (ExtendableEventInit dict) > ExtendableMessageEvent (ExtendableMessageEventInit dict).

I don't really see how to make that work. (If inheritance worked for dictionaries here it would also work for the interface side of things, no?)

[bzbarsky]

Oh, I see. I hadn't realized that the ExtendableEventInit thing was in there too.

Then yeah, doing this does require mixins. :(

[palemieux]

@tobie Any follow-up on the plan to add dictionary mixins (#363 (comment))? This would help document only once properties used in multiple dictionary types.

[tobie]

None at present, unfortunately.

[palemieux]

@tobie Ok. In the meantime, any recommendation for specifying complex dictionary structures intended to be passed to Web APIs?

[dcrousso]

Is there still any interest in adding this? I have a possible use for it in WebKit.

In my opinion, allowing dictionary mixin (and partial dictionary mixin) seems like a natural way to compose objects, especially since there is no class/prototype that's created/exposed for a dictionary to the page. dictionary is really just a bag of key->value, so where each of those key->value comes from (whether that be via direct inheritance or some includes) isn't really that important.

[bathos]

@dcrousso the property [[Get]] order, as bzbarsky mentioned, does expose the inheritance chain to ES code. Within a single "tier", keys are sorted lexically, but the access order is one-tier-at-a-time. If they were always sorted across the chain, the exposure would go away, but that likely isn't web compatible (and might lead to problems for implementers).

One ordering solution for mixins would be to handle them like partials: "these keys belong to the includes-target, so they get sorted lexically among the others". I'm pretty sure that would keep the access order well-defined without borking anything that already exists?

[annevk]

For dictionaries in particular I think we should keep lexicographical ordering. If we have dictionary mixins, that would be across all of the members. I agree that's not possible for interfaces/classes. There per-thing is probably the best we can do.