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

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);
* the properties of the prototype ancestors to be overridden by all of
the mixins;
* if you could access the mixin prototype object, and it was shared
between two interfaces, modifying it would change both interfaces

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.

For example, the WebIDL specification could say something like:

> When the [[Get]] method of an interface prototype object, O, is called with property name P, the following steps are taken:
> 1. If O doesn't have a property with name P, go to step 4.
> 2. Get the value of the property.
> 3. Return Result(2).
> 4. Get the next parent of O. If there are no more parents, return undefined.
> 5. Call the [[HasProperty]] method of Result(4) with property name P.
> 6. If Result(5) is false, go to step 4.
> 7. Call the [[Get]] method of Result(4) with property name P.
> 8. Return Result(7).

[[CanPut]] and [[HasProperty]] would be changed in a similar fashion.

The parents of an object should also be defined (in relation to grammar
productions).

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.

I think this way of implementing multiple inheritance is somewhat
cleaner than the copying of methods onto another object.  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?

Any comments/suggestions would be appreciated.

-- 
Andrew Oakley

Received on Thursday, 20 August 2009 12:32:14 UTC