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

On Sat, 20 Nov 2010, Cameron McCormack wrote:
> 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?

Wouldn't that result in two interfaces in Java? There really is only one 
interface here, it's just specified in two different places.

Another example is Navigator, which is defined in both Web Workers and 
HTML; they mix in various interfaces but the goal is for the platform to 
only have two Navigator interfaces (one for Window contexts, one for 
workers); the "abstract" interfaces don't exist as anything but a didactic 
aid in the spec(s).

Another example is DOMException, where the interface has at various times 
been defined in various specs; e.g. for the moment the HTML spec has a 
[Supplemental] DOMException interface that adds a few codes. This will 
change once I get around to updating the spec for recent DOM Core changes, 
but the point is that when I do that change, it should have zero impact on 
any implementations, since they'd already just have a single interface {} 
block in their code, not two like in the spec.


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

Yes.


> They’d be concrete interfaces, but you don’t want there to be a 
> separate prototype for them?

I want them to be concrete interfaces that don't inherit from anything, 
and there's only ever one of the two in any one context. However, I don't 
want to have to specify the common bits twice, and I want them to have the 
same name from the point of view of the programmers, but in the spec I 
need them to have different names so that I can define things for each one 
separately.


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

Poor terminology. I mean that the object's interface as seen from code is 
different -- specifically, a Window created by showModalDialog() has two 
extra members in its instance of "Window", there's no extra interface 
around. I guess it doesn't much matter how we do this particular one since 
anyone implementing Window in Java is going to want to shoot themselves 
pretty regularly anyway; that interface is just bonkers.


> Is the idea that normally, window objects just implement Window, but 
> when they are created using showModalDialog, they have additional 
> properties dialogArguments and returnValue?

Yes.


> Is the issue that you don’t want to write `Window implements 
> WindowModal;`, since not all windows implement it?

Yes.


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

Wouldn't that make WindowModal visible to the world, if we don't have 
NoInterfaceObject? I guess if WindowModal is defined as a "mixin 
interface" then it's just not there in JS, so it's a moot point.

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

It might make sense just to have a "sometimes implements" statement that 
is required to have corresponding prose (much like we do with getters and 
setters), so one would say:

   Window sometimes implements WindowModal;

...and then add the prose you suggest above.


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

I meant in the places where the identifier is used, not where it's 
defined, as in:

   Window implements mixin WindowTimer;

...but if they're the same namespace as interfaces and visible in Java 
regardless (i.e. they're not just a spec detail) then there's no real 
benefit to doing this.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'