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

Cameron McCormack:
> > An alternative would be to just require that the SVGZoomAndPan
> > object exists with these constants as a legacy-required thing, and
> > that for future (other) specs, script authors would just need to
> > look up the constants on the concrete interface being mixed in to.

Boris Zbarsky:
> Which one, though?  It's not obvious that looking up Window.something
> is the same as Node.something if we have an interface that mixes into
> both....

They’d be on all prototypes (and interface objects) of the LHS-of-the-
implements-statement interfaces.

  mixin interface Frobable {
    const long FROB_TYPE_A = 1;
    const long FROB_TYPE_B = 2;

    void frob(in long type);
  };

  interface Node { … };
  Node implements Frobable;

  interface XMLHttpRequest { … };
  XMLHttpRequest implements Frobable;

then:

  Node.FROB_TYPE_A == 1
  Node.prototype.FROB_TYPE_A == 1
  XMLHttpRequest.FROB_TYPE_A == 1
  XMLHttpRequest.prototype.FROB_TYPE_A == 1

> I don't think this is a blocking issue, but did want to mention it.

It’s perhaps non-obvious for the specification reader that you need to
look these constants up on things other than window.Frobable, true.

> (Well, the other issue is that if you want to override the default
> behavior of a mixin method that mixes into lots of places then you have
> to do it in all those places separately... this may also be ok.)

I think we’re at the point where most people think this is an acceptable
limitation.

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

Received on Monday, 22 November 2010 23:32:55 UTC