Re: Prototype chain for objects that implement multiple interfaces

Boris Zbarsky:
> As a result, given a <div> object (call it "div"),
> 
>   div.[[Prototype]] === HTMLDivElement.prototype
>   HTMLDivElement.prototype.[[Prototype]] === HTMLElement.prototype
>   div.appendChild === HTMLDivElement.prototype.appendChild
> 
> are all true, while
> 
>   div.appendChild === HTMLElement.prototype.appendChild
> 
> is false.  As a result, to change what the appendChild of a <div> is you 
> have to change it on HTMLDivElement.prototype.

Interesting.

> Of course all of this is subject to change, and in fact is likely to change 
> some time in the not too distant future.
> 
> To be honest, do we really think that specifying the exact prototype chain 
> is desirable?

I wondered that myself, but it would help the case where script authors
want to mess about with the prototypes of various objects.  Perhaps it
doesn’t need to be specified exactly, but with enough fixed down such
that you could reliably assign to HTMLElement.prototype.appendChild and
expect it to affect your div element.

> How likely are UAs to rework the mappings between their native code
> and ECMAScript to follow said spec?

Fair point, and I don’t want to go writing mounds of text if nobody
cares enough to implement it.  I imagine the likelihood depends on how
far the spec diverges from the implementation.  How about for Mozilla,
assuming something “sensible” was specified that allowed script authors
to know in which prototype object methods from a particular interface
are to be found so that they can overwrite them?

-- 
Cameron McCormack, http://mcc.id.au/
 xmpp:heycam@jabber.org  ▪  ICQ 26955922  ▪  MSN cam@mcc.id.au

Received on Wednesday, 6 June 2007 05:44:34 UTC