Add support for WebIDL mixins

NEW
Unassigned

Status

()

Core
DOM
P3
normal
16 days ago
13 days ago

People

(Reporter: Tobie Langel, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

16 days ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36

Steps to reproduce:

Hi all!

WebIDL recently introduced dedicated syntax for mixins[0].

This syntax replaces the [NoInterfaceObject] extended attribute and "implements statement" which have been deprecated (except for a few legacy uses cases explicitly mentioned in the spec[1]).

You can read more about it in the spec[2].

In most cases, the changes should be relatively straightforward. The now deprecated:

    interface Foo { };

    [NoInterfaceObject]  // (Mostly) DEPRECATED
    interface Bar { };
    Foo implementes Bar; // DEPRECATED


should just be rewritten as:

    interface Foo { };
    
    interface mixin Bar { };
    Foo includes Bar;

Please feel free to reach out if you have any questions.

Thanks!

[0]: https://github.com/heycam/webidl/commit/45e8173d40ddff8dcf81697326e094bcf8b92920
[1]: https://heycam.github.io/webidl/#NoInterfaceObject
[2]: https://heycam.github.io/webidl/#idl-interface-mixins

This is tracked in: https://github.com/heycam/webidl/issues/472
The original pull-request: https://github.com/heycam/webidl/pull/433
Tobie, were there semantic changes too?

For example, it sure looks to me like MixinMember doesn't allow everything allowed in InterfaceMember, right?

What (if anything) replaced the concept of "consequential interfaces"?  It looks like it's not possible for a mixin to include another mixin, right?  Instead, all the interfaces including the first mixin would have to manually include the second one?
Flags: needinfo?(tobie.langel)
(Reporter)

Comment 2

16 days ago
> Tobie, were there semantic changes too?

Yes. Mixins are much simpler (and more restricted) than what we previously had.

> For example, it sure looks to me like MixinMember doesn't allow everything allowed in InterfaceMember, right?

Yes. I took the Gecko code code and ran the following commands on it:

https://gist.github.com/tobie/bb83f160e93a084afdfb74ae29fddf2a

This allowed identifying what was really needed in practice:

https://github.com/heycam/webidl/issues/363#issuecomment-325821479

> What (if anything) replaced the concept of "consequential interfaces"?

Nothing. I couldn't find examples where that was actually needed.

> It looks like it's not possible for a mixin to include another mixin, right?  Instead, all the interfaces including the first mixin would have to manually include the second one?

That's correct. Alternatively a partial mixin could be used instead.

In practice I didn't find mixins that were implementing other mixins.
Flags: needinfo?(tobie.langel)
The key difference between a partial mixin and a mixin pulling in a mixin is this.  Say we have three specs: A, B, C.  Spec A defines mixin 1.  Spec B wants to define mixin 2 that includes all of mixin 1 but adds some things; it does not want to extend mixin 1 because it doesn't want to affect all the consumers of mixin 1.  Spec C wants to use the mixin spec B defines.  With what's in the IDL spec right now, C has to manually pull in both B's mixin and A's mixin instead of just pulling in B's mixin.  In particular, that makes it harder to factor part of B's mixin out of B into a new spec (A).

> In practice I didn't find mixins that were implementing other mixins.

We have two standard-ish ones in the Gecko tree, based on debug print statements I just added to our binding generator: XPathEvaluator and WebGL2RenderingContextBase.

XPathEvaluator doesn't really have a spec yet (and is an implemented interface that is NOT [NoInterfaceObject] to boot; it can probably be factored out into a separate mixin pulled in by both that interface and Document).  WebGL2RenderingContextBase comes from https://www.khronos.org/registry/webgl/specs/latest/2.0/ and is very much a mixin implementing a mixin:

  WebGL2RenderingContext implements WebGL2RenderingContextBase;
  WebGL2RenderingContextBase implements WebGLRenderingContextBase;

We also have a non-standard "BrowserElement" mixin which implements two other mixins (BrowserElementCommon/BrowserElementPrivileged), but we could probably get rid of that indirection, since nothing else implements them.
(Reporter)

Comment 4

16 days ago
Can't the WebGL example be expressed just as well as:

    interface mixin WebGL2RenderingContextBase {
      /* ... */
    };
    
    interface WebGL2RenderingContext { };
    WebGL2RenderingContext includes WebGLRenderingContextBase;
    WebGL2RenderingContext includes WebGL2RenderingContextBase;
I did ask them about this at the time we implemented webgl2, fwiw.  They are doing this very purposefully, so when they introduce a WebGL3RenderingContext they don't have to explicitly write down that it implements all the preceding "base" interfaces; they can just say that it implements WebGL2RenderingContextBase and that picks up WebGLRenderingContextBase automatically.

In any case, the upshot is that if webidl doesn't support this then we need to get khronos to change how they're doing things.

In practice, I suspect allowing mixins to include other mixins is simpler than trying to get people to not do it.
(Reporter)

Comment 6

16 days ago
Yeah, I filed two bugs earlier today:

- https://github.com/KhronosGroup/WebGL/issues/2538
- https://github.com/KhronosGroup/WebGL/issues/2539
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.