W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2010

Re: [WebIDL] prototype chains, multiple inheritance, mixin interfaces

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 24 Nov 2010 11:45:20 +1300
To: Anne van Kesteren <annevk@opera.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, public-script-coord@w3.org
Message-ID: <20101123224520.GB10897@wok.mcc.id.au>
Cameron McCormack:
> > It might be that the intention, for these editorial splitting cases,
> > that the split will never be across specification boundaries.  If we
> > could somehow require that, it would make me feel a bit better about
> > allowing it.

Anne van Kesteren:
> That is not the case. http://dev.w3.org/csswg/cssom-view/ makes a
> number of extensions to existing interfaces, such as Window,
> Document, Element, and HTMLElement.
> http://html5.org/specs/dom-parsing.html does this as well.

Hrmph. :)  Again, I could say that these cases could be solved like

  /* in HTML5 */
  interface Window { … };

  /* in CSSOM */
  mixin interface WindowCSS {
    MediaQueryList matchMedia(DOMString media_query_list);
    …
  };
  Window implements WindowCSS;

and

  /* in DOM Core */
  interface Element { … };

  /* in DOM Parser */
  mixin interface ElementParsing {
    attribute DOMString innerHTML;
    …
  };
  Element implements ElementParsing;

I suppose what it comes down to is whether you’re really defining a new,
separate interface, or if you are just redefining/extending the existing
interface without having to re-include all of the existing stuff from
the original spec.  I can believe that both of these cases can (and do)
arise.


My objection based on the possibility of encouraging Java binary
compatibility problems may have been too strong.  I imagined this
situation:

  * Interface A is defined initially in Specification 1:
      interface A { void f(); };

  * Specification 2 comes along and supplements A:
      [Supplemental] interface A { void g(); };

  * Specification 3 comes along and also supplements A:
      [Supplemental] interface A { void h(); };

  * Implementation X implements Specification 1+2’s idea of A.

  * User writes code that uses functionality from Specification 1’s
    definition of A, and compiles against Implementation X’s interface.
      class User { void user(A a) { a.f(); } }

  * Implementation Y implements Specification 1+3’s idea of A.

  * User tries to run compiled code against Implementation Y, which
    fails due to binary incompatibility.

But in fact I found with testing that that last step seems to be fine:
even though switching from Implementation X to Implementation Y has
“lost” the g() method, it doesn’t actually matter and the code will run.


My first two objections in
http://lists.w3.org/Archives/Public/public-script-coord/2010OctDec/0084.html
were less strong, so I am prepared to concede that we can allow
“partial” interfaces or something similar in the IDL.  I think it should
be a core feature, rather than specified with an extended attribute.

In languages like C#, partial interfaces are written like this:

  // Initial definition from DOM Core
  public partial interface Element {
    DOMString getAttribute(DOMString name);
    // …
  }

  // Extension from, say, DOM Parsing
  public partial interface Element {
    void insertAdjacentHTML(DOMString position, DOMString text);
  }

The first definition is required to be marked as partial as well as all
the supplemental ones.  Presumably this is so that the compiler knows,
if it encounters the “base” interface first, that it can’t just write
out the compiled interface file at that point.  I don’t think we need to
require this given that for “mixin interfaces” you basically have to
know about all of the interfaces in your codebase when compiling one
interface anyway.


Here is my proposal then.  For both the “editorial” case (like how the
deprecated members of HTMLBodyElement are separated in HTML5 from the
rest purely for editorial reasons) and the “extension” case as in the
above CSSOM and DOM Parser examples, we allow interfaces to be extended:

  // in DOM Core
  interface Element : Node {
    DOMString getAttribute(in DOMString name);
    …
  };

  // in DOM Parser
  extend interface Element {
    void insertAdjacentHTML(DOMString position, DOMString text);
    …
  };

We would still allow mixin interfaces to be defined and then used with
“implements” statements for cases where they really are more like
separate interfaces.

WDYT?


[I don’t particularly like “supplemental” as the keyword to use, as it
sounds like it’s really a separate interface – more like the mixin case.
Although I am not that happy with “extend”, either, as it sounds more
like a command than some declarative statement of fact like “implements”
does.  Bikeshedding welcome! :)]

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Tuesday, 23 November 2010 22:46:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 May 2013 19:30:03 UTC