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?

The latter.


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

It's confusing for the spec to use interface names that don't really 
exist, just to work around a limitation in WebIDL's expressiveness.


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

Right.


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

There's only ever one of them in a particular scope at a time, and I want 
it to be called "WorkerGlobalScope" (so that scripts don't have to worry 
about which it is), but in the spec I have to define it as two because 
they are different.


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

The idea is that utility scripts will find that dedicated and shared 
workers are essentially the same thing, and only the machinery that needs 
to talk to outside the worker needs to worry about the difference. By 
having them appear to use the same class except for a few differences, we 
avoid unnecessary differences (like the class' name).


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

It exposes different members.


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

Ok, I've added this text.

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