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

Ian Hickson:
> This only removes one of the use cases for [Supplemental]; there are still 
> some others, e.g. having a concrete interface be defined in several 
> different specs (q.v. HTMLBodyElement),

What specs other than HTML5 is HTMLBodyElement defined in?  Or is just
the two pieces in HTML5?  You could of course use a name on the part
that defines the presentational attributes and use an implements
statement.  Is there a reason that won’t work?

> and having a hierarchy get flattened (e.g. DedicatedWorkerGlobalScope
> and SharedWorkerGlobalScope vs WorkerGlobalScope).

So in this case, a WorkerGlobalScope can be either a
DedicatedWorkerGlobalScope or a SharedWorkerGlobalScope, is that right?
They’d be concrete interfaces, but you don’t want there to be a separate
prototype for them?  Then yes, that wouldn’t be possible if we dropped
(or failed to introduce) [Supplemental].  It seems a bit different from
the mixing-in case.  What is the reason this is desired, by the way?

> So we likely still need [Supplemental]. There's also the weird magic does for
> e.g. WindowModal, where the Window "class" is different in different
> contexts; should that just be done in prose?

What is meant by the “class” being different?

Is the idea that normally, window objects just implement Window, but
when they are created using showModalDialog, they have additional
properties dialogArguments and returnValue?  Is the issue that you don’t
want to write `Window implements WindowModal;`, since not all windows
implement it?  I think in this case we don’t need [Supplemental], but we
just have a sentence in there like you have already.  I’d word it more
like this though:

  The Window objects of Documents hosted by browsing contexts created by
  the above algorithm must also implement the WindowModal interface.

And then when I write up the new prototype stuff in Web IDL I’ll make
sure that when there is no implements statement that causes an abstract
interface to be implemented by an object, then the mixed in properties
go to the most derived concrete interface’s prototype.

> Overall this idea seems great.

Excellent. :)

> What's the syntax going to be? "abstract interface Foo { ... };" ?

Not sure yet.  As some other people mentioned during the discussions,
“abstract interface” sounds kind of weird.  I’m not sure I like calling
the concrete ones “class”, either, especially since in other languages
like Java they’ll still be exposed as interfaces.

So my current thinking is “interface” for the concrete ones and “mixin
interface” or maybe just “mixin” for the abstract ones.  But I suggest
not to make changes until I’ve done the changes in Web IDL.

> Is the namespace for the abstract interfaces the same as for the
> concrete classes?

Yes.

> Presumably the names of abstract interfaces are now purely a spec
> detail;

Except that in the Java binding they need to correspond to real Java
interfaces, so the names are important there.  But in the JS binding
they are unimportant.

> should they all be prefixed with some special indicator to show that
> they're not "real"?

The syntax (“mixin interface” or whatever) would be the indication.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 19 November 2010 22:47:51 UTC