Re: removing multiple inheritance

Hi Travis.

Travis Leithead:
> I can offer my thoughts from an implementation point of view.
> 
> First, I think this is definitely the right direction, and I'm happy
> to see the spec moving in this direction.

Cool.

> >* regular interfaces can inherit only from a single other regular
> >  interface
> 
> In IE9's implementation, we also allow mixin interfaces to have
> single-inheritance. When such an interface is used as the RHS of an
> implements statement the list of relevant APIs to copy includes APIs
> from that interface's inheritance chain (in addition to including
> mixin interfaces that are implemented by other mixin interfaces). For
> example, we have the following:
…

Yeah, that makes sense.  I would keep allowing that.

> In practice, this capability is only used in 2-3 places and could
> quite easily be refactored if the extra complexity is not worth
> specing.

I think it’s not too much complexity.

> (Can I say that refactoring the SVG spec into WebIDL in a
> mostly-interoperable way was quite an undertaking?)

Ha, I’d believe that.  This would actually be useful for us in the SVG
WG, when we come to rewriting the IDL in Web IDL.  If you are able to,
mailing your Web IDL for SVG to www-svg (or me) would be helpful,
thanks!

…
> >The WindowModal one is an interesting case, because for each distinct
> >Window (global) object there is a whole set of interface objects,
> >prototypes, etc.  So it would actually be safe to put the WindowModal
> >properties on Window.prototype directly.  If you could restrict it just to
> >the environment created by showModalDialog, you could
> >
> >  Window implements WindowModal;
> >
> >but as it stands the statement above would apply to all sets of “initial
> >objects”. http://dev.w3.org/2006/webapi/WebIDL/#es-environment
> 
> Yes. And in IE9 we punted on a syntactic way of indicating this. I
> love Ian's magic syntax (now replaced with more descriptive spec
> language):
>
> Window implements WindowModal; // sometimes
> 
> This may be worth having a special declarative syntax...on the other
> hand, new specs should probably not do this type of conditional
> binding. I curious to hear what others think about this.

I think you are right that this isn’t the kind of thing we should
encourage new specifications to do.

I wonder if there is any impediment to having

  [NoInterfaceObject]
  interface ModalWindow : Window {
    readonly attribute dialogArguments;
    attribute DOMString returnValue;
  };

instead.  It does mean there is a separate prototype object, true, but
it does simplify the issue and doesn’t require different looking Window
prototype objects in different contexts.

Ian: is this feasible?

…
> >  interface AbstractThingamy { ... };
> >  interface InteractiveThingamy : AbstractThingamy { ... };
> >  InteractiveThingamy implements EventTarget;
> >
> >That would be disallowed in this proposal, since the RHS of the implements
> >statement is a regular interface.
> 
> In practice, we [IE9] haven't needed to support this yet. We treat
> EventTarget as [NoInterfaceObject] currently. However, if we changed
> to the above DOM Core proposal, then we'd have to do some refactoring
> of the object hierarchy to fit it in without using it in the RHS of an
> implements statement.

Yeah.  But but if you made the changes to match DOM Core, would you have
some objects implementing EventTarget because it inherits from it, and
others implementing it because it appears on the RHS of an implements
statement?

> >One of the advantages of the proposal was that by never having an interface
> >prototype object for mixins, you avoid authors mistakenly thinking that
> >modifying that object will affect all objects that implement that
> >interface.  If we allow the above, then we have a distinct prototype object
> >for EventTarget, and changes to it will affect Node and XHR objects but
> >will have no affect on InteractiveThingamy objects.
> 
> ...if you allow the above, this is the behavior that I would expect
> (because EventTarget.prototype would have one instance of the API, and
> InterfaceThingamy.prototype would have another copy).

Yes.

> >Another advantage was that by not having an interface object, we don’t have
> >to worry about having custom [[HasInstance]] behaviour and we can always
> >just rely on the native “look up the prototype chain”
> >semantics.
> 
> Yep. The fewer alterations that the DOM has to make to the default
> JavaScript behavior, the better. That's my overall viewpoint.

Also agreed.

> >I think the strongest reason for reforming interface inheritance in Web IDL
> >is to ensure that mixed-in interface properties get placed on the right
> >objects.  So that, for example, the WindowTimers properties setTimeout etc.
> >get put on Window.protoype, because `Window implements WindowTimers`.  I
> >would be fine with not making the distinction between regular and mixin
> >prototypes, bearing the cost of possible author confusion when
> >modifications to EventTarget.prototype (in the example
> >above) don’t affect InteractiveThingamy, and keeping [NoInterfaceObject]
> >annotations on interfaces that really are mixins and which are unlikely to
> >appear as the ancestore of another interface.  I think that is the simplest
> >change to make, but I am interested to hear others’ opinions.
> 
> In either case, I'd rather *not* see a new type of interface
> just for mixins, e.g., mixin Foo {} which might be equivalent to
> [NoInterfaceObject] interface Foo {} because of the extensive use of
> [NoInterfaceObject] today.

Why?  Because there are many of them?

I think if we *don’t* disallow interfaces from being both on the RHS of
an implements statement and in the inheritance hierarchy of regular
interfaces, then there isn’t much to gain from distinguishing these two
cases in the IDL (with “interface” vs “mixin” or whatever).

But if we do disallow this, then I think it does make sense to
distinguish these two kinds of interfaces more strongly in the IDL.  If
mixins are always [NoInterfaceObject] and must never appear as a super-
interface of a regular interface, then why not have a single syntactic
way of indicating this?

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

Received on Thursday, 16 June 2011 00:51:21 UTC