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

On Fri, 19 Nov 2010, Jonas Sicking wrote:
> >
> > Wouldn't that result in two interfaces in Java? There really is only 
> > one interface here, it's just specified in two different places.
> 
> Does that matter? Is Java an important enough use case that we need to 
> add special constructs just to keep the number of interfaces down? 
> Looking at SVG, it doesn't seem like Java people shy away from having 
> many interfaces.

Stuff moves from one to the other as we deprecate stuff. If we use two 
different interfaces here, it means that later we will break code that 
uses this because a member changed from one interface to another. If we 
don't care about this, then we shouldn't pretend to actually cater to Java 
(and should remove the Java part of WebIDL), IMHO.

(This is in fact already a problem of sorts since some stuff on 
HTML*Element has been moved to the deprecated HTML*Element interfaces in 
the HTML spec, so if anyone implement DOM2 HTML they would be affected.)


> > 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).
> 
> You could do Navigator exactly the way you're currently do it, just
> change the base object to use 'class' rather than 'interface'. [...]

That's fine for JS, but it exposes a spec detail in the Java code.


> Though really, i'm not sure what having all these interfaces buys you.

It makes it easier to unambiguously define the members of these 
interfaces, since there's only one of each, rather than having two as in 
the obvious simpler presentation (flattening the two interfaces and having 
one of them just say "and this member does the same as that member" over 
and over).


> >> > 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.
> 
> You should be able to use the same solution as described above:
> 
> class DedicatedWorkerGlobalScope {
>   void postMessage(in any message, in optional MessagePortArray ports);
>            attribute Function onmessage;
> };
> DedicatedWorkerGlobalScope implements WorkerGlobalScope;
> DedicatedWorkerGlobalScope implements WorkerUtils;
> DedicatedWorkerGlobalScope implements EventTarget;
> 
> class SharedWorkerGlobalScope {
>   readonly attribute DOMString name;
>   readonly attribute ApplicationCache applicationCache;
>            attribute Function onconnect;
> };
> SharedWorkerGlobalScope implements WorkerGlobalScope;
> SharedWorkerGlobalScope implements WorkerUtils;
> SharedWorkerGlobalScope implements EventTarget;
> 
> interface WorkerGlobalScope {
>   readonly attribute WorkerGlobalScope self;
>   readonly attribute WorkerLocation location;
> 
>   void close();
>            attribute Function onerror;
> };

That would give the JS objects the wrong name (specifically, names that 
differ in dedicated vs shared worker contexts).


> You don't have to specify a function twice just because it appears in 
> two interfaces. You can always refer to the first "copy" when specifying 
> the second.

One can do that, but in my experience this ends up with more buggy specs.


> >> > 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.
> 
> WebIDL aside this seems like a complicated situation. In ECMAScript, 
> would the prototype object be different in a showModalDialog-created 
> window from that of a "normal" window? Or would these extra properties 
> just appear as properties on the instance itself?

Browsers differ in how they do this but my intent is the former.


> I think what would make the most sense is to remove the WindowModal 
> interface entirely and just say that these appear as properties on the 
> instance. Having different prototype objects is pretty ugly.

I don't have a big opinion on what we spec in terms of the requirements on 
implementations, but I definitely want WebIDL to be expressive enough to 
make it possible to define what is supposed to happen here with minimal 
prose, leveraging all of the WebIDL definitions. So I do think we want 
some IDL involved.

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