W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2011

Re: removing multiple inheritance

From: Cameron McCormack <cam@mcc.id.au>
Date: Thu, 16 Jun 2011 16:22:38 +1200
To: Ian Hickson <ian@hixie.ch>
Cc: Travis Leithead <Travis.Leithead@microsoft.com>, public-script-coord@w3.org
Message-ID: <20110616042238.GI21000@wok.mcc.id.au>
Cameron McCormack:
> > 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?

Ian Hickson:
> The question is more whether UAs want to do it.
> Personally I'd rather use a [Supplemental] interface (i.e. one that is 
> indistinguishable from the spec just defining Window with the new 
> properties), but what matters isn't what I want, it's what gets 
> implemented. I'm happy to spec whatever gets implemented. I haven't looked 
> closely at how closely the spec matches reality on this particular issue 
> since it's not a high priority.

I just wrote a quick test:


It seems that in all of Firefox, Chrome, Safari and IE, dialogArguments
is an own property on the window object.  There’s no way to express that
at the moment in Web IDL.

Having them as own properties at least means that there’s no need to
have two different looking Window.prototype objects for regular and
modal windows.

> From the authors' perspective, it's just that this is a Window that 
> happens to have extra features. I don't think authors look at this as 
> Window+ModalWindow, nor would they expect code which works on the Window 
> prototype chain to break when faced with the ModalWindow chain just 
> because it had a different number of prototypes or anything like that.

(The web will probably prove me wrong as soon as I type this, but) I
would think it’s pretty unlikely that sites rely on the fact that
dialogArguments and returnValue are on any particular object in the
window’s prototype chain.

> BTW, on the EventTarget thing, I think it'd be great if there was some way 
> in which we could rig things so that authors could override one object and 
> hit _all_ the EventTarget-implementing objects, not just Nodes. I don't 
> know if that's really possible in JS, but it certainly seems like what 
> authors would want, like the most useful API.

I did consider this, some time ago.  The cleanest of several possible
ways to do this would be to have mixed in properties just delegate to
the property on the interface prototype object.  So, if we assume that
EventTarget is not an ancestor of Node (but is mixed in to Node, and
others), it would be implemented like this:

  Node.prototype.addEventListener = function() {
    <original value of EventTarget.prototype>.addEventListener
      .apply(this, arguments);
But if what you want is for assigning to Node.prototype.addEventListener
to update all mixed in addEventListener properties, which is something
you’d need if you have only mixins and don’t expose an interface object,
then I think this is kind of complicated and out there, and at a guess
not something that would be received enthusiastically. :-)

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 16 June 2011 04:23:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC