Re: [WebIDL] mixins and [[Prototype]]s (and <object>s)

Hi Andrew.

Andrew Oakley:
> The idea of mixin prototype objects in the WebIDL specification does not
> seem intuitive, simple to implement or efficient.  Specifically there is
> some odd user visible behaviour:
> 
> * modifying the interface prototype objects for the mixins does not
> change the mixin prototype object (e.g. if you added a new property it
> would not be visible);

True.  (We could make the prototype objects for the mixing interfaces
special, such that e.g. doing ‘EventTarget.prototype.a = 1’ would cause
a property ‘a’ to be created on the relevant mixin prototype objects.)

> * the properties of the prototype ancestors to be overridden by all of
> the mixins;

Yeah, that’s unfortunate too.  It’s that way because it’s simpler to
make __proto__ of the mixin prototype object point to a regular
interface prototype object than vice versa.

> * if you could access the mixin prototype object, and it was shared
> between two interfaces, modifying it would change both interfaces

Right.  But that’s the same as if you modify Node.prototype, then you
are changing Elements, Texts, Comments, etc.

> Is it not possible to simply change how [[Get]] (and friends) works on
> the interface prototype object so it attempts to look up properties on
> all of the relevant interface prototype objects?  This could be
> specified in a recursive manner to produce a depth first search of the
> interface hierarchy, or it could be written using a more complex
> approach such as C3 ordering which seems to have become fashionable
> recently.

Something similar to this, but without the C3 ordering (which David
Andersson suggested at one point), was in an earlier draft:

  http://www.w3.org/TR/2008/WD-WebIDL-20080829/#interface-prototype-object

IIRC there were concerns raised about breaking the explicit prototype
chain and it being more of a burden to walk this inheritance tree for
property lookups.

> …
> I think the rules for what to use as the [[Prototype]] (the
> [PrototypeRoot] attribute) are reasonable.  This will affect at least
> Object.prototype.isPrototypeOf, and probably a number of other things I
> haven't thought of yet.

OK.

> I think this way of implementing multiple inheritance is somewhat
> cleaner than the copying of methods onto another object.

I agree.

> It also makes it much simpler to deal with <object> elements - if we
> load an nsplugin (we may change which nsplugin is used of the lifetime
> of the <object>) we can just add the object created by the npruntime
> API as another parent of the HTMLObjectElement host object. How would
> you implement sensible behavior using the method described in the
> WebIDL specification?

I haven’t been taking the use case of allowing the set of interfaces an
object implements to change into account.  Is treating the JS interface
that NS plugins expose as an IDL interface that the HTMLObjectElement
must then also implement the way to think about it?  Without looking at
any code to see how it’s currently done, I would probably just change
[[Get]], etc. on HTMLObjectElement such that it takes the plugin’s
interface into account.

Admittedly that would violate the requirement that the [[Get]] of a host
object operate in a particular way.

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

Received on Sunday, 30 August 2009 23:25:15 UTC