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

Cameron McCormack wrote:
>> * 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.)

OK, but this could potentially change the (unspecified) resolution order
if it isn't implemented carefully.  What happens if we [[Delete]] a
member on the mixin prototype object? (That might be a somewhat academic
question as you should not be able to access it, but Gecko based
browsers give you a __proto__ property.)

> …
>> * 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.

OK, but it is awkward to implement.

>> 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 had seen the email that is linked to by that edition of the spec, and
agree that without a sensible MRO it was broken.  I don't see that
"breaking the explicit prototype chain" is more of a problem than making
[[Put]] cause the property to be created on more than one object though.
 Were there any mailing list threads that I could look at so I could
understand why this was a problem?  I've implemented the scheme I
proposed since writing my last mail, and I haven't found any significant
problems (currently testing), but I guess how easy this is to do depends
on how inheritance is currently implemented.

> …
>> 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.

I'm not sure how the major vendors handle the nsruntime object, the
documentation doesn't seem clear.  I guess it is possible to handle it
in the way you suggested.  This (ab)use of [[Get]] seems similar to how
the WindowProxy object works in HTML5, so it wouldn't be the first time
its been done (and we change the prototype objects rather than actually
implementing the HTML5 behavior here).

CE-HTML allows audio and video to be embedded using <object>, and gives
interfaces for these cases.  The implication seems to be that there
should be interface prototype objects for these.  I *believe* Opera has
support for CE-HTML (but perhaps not on the standard versions, a quick
google shows that someone has spotted one in a User-Agent header), so it
would be interesting to find out how that behaves.

-- 
Andrew Oakley

Received on Thursday, 3 September 2009 08:13:48 UTC