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

Jonas Sicking:
> > > 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.

Ian Hickson:
> > 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.)

Jonas Sicking:
> Is this something that Java developers have really asked for? I
> can't recall seeing any such requests on neither this nor the
> public-dom/public-webapi/public-webapps lists over the many years I've
> followed them.

I don’t think Java developers have asked for fewer interfaces, but there
are very specific changes that can be made to Java interfaces while
retaining binary compatibility.

  http://java.sun.com/docs/books/jls/third_edition/html/binaryComp.html#45337

Now, I don’t want to say “please don’t ever remove interface members
when rationalising the web platform because you’ll break Java”.  Those
writing the Java interfaces can work around this by just keeping those
methods in there (and having them simply throw), or moving them to a
superinterface.  All I want is that if a problem can be solved equally
well while not breaking other languages, then we should prefer that.

The issue of moving things to “deprecated HTML*Element interfaces”, is
this the same thing as the HTMLBodyElement example?  There isn’t a
desire to have these on actual separate interfaces, right?  They’re just
defined in the “Obsolete features” section to hide them from readers of
the rest of the spec?  Here is why I don’t want to have a mechanism to
“re-open” interface declarations in Web IDL:

  * Instead of looking in a single place in one spec, you now need to
    look across all the specs you implement to be sure that you have
    everything from that interface.

  * The question “does object X implement interface A?” makes less sense
    if A could be split up across two or more definitions, where
    possibly only some of the specs in which the pieces are defined are
    implemented.

  * For languages like Java, binary compatibility is broken if you
    remove members from the interface.  If you have interface A split
    into three separate IDL fragments over three specifications, then
    one implementation might have A1+A2 while another has A1+A3.  These
    two interfaces are not binary compatible.

Can we solve this another way?  Are there any other use cases for using
[Supplemental] with an already existing interface name?

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.

> > […]
> >
> > That would give the JS objects the wrong name (specifically, names that
> > differ in dedicated vs shared worker contexts).
> 
> The fact that workers now have two different definitions of
> WorkerGlobalScope seems bad to me. Different names seem better.

I agree.  It seems like inheritance is the normal solution to this
problem (with common definitions on the base interface).  Why is the way
HTML5 currently defines it, but without having [Supplemental,
NoInterfaceObject], not acceptable?

> > > 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.
> 
> Both from an implementation point of view, and from a js-author point
> of view it seems better that prototype objects are the same in
> different windows and that these properties show up on the instance
> instead.

Why does regular inheritance not work here, either?  Specifying in prose
that the Window object has a few extra properties on the instance would
definitely mean that this wouldn’t be usable in other languages.

The “sometimes implements” (and my suggestion earlier of just having Web
IDL say that the most-derived interface’s prototype gets augemented)
would be problematic, I agree.  For such cases, we would need to keep
something like the mixin prototype object.

> If people really think that we should keep [Supplemental] in order to
> keep down the number of java interfaces, or to keep them more stable I
> would be fine with that. But I'd like to make sure that this is
> something that Java developers really need and want.

I don’t think keeping the number of Java interfaces down is a goal, and
I don’t think we need [Supplemental].

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

Received on Monday, 22 November 2010 23:23:21 UTC