W3C home > Mailing lists > Public > public-webapi@w3.org > June 2007

Re: Prototype chain for objects that implement multiple interfaces

From: liorean <liorean@gmail.com>
Date: Wed, 6 Jun 2007 11:26:49 +0200
Message-ID: <cee13aa30706060226u273111edmbebd90ae4252d713@mail.gmail.com>
To: "Web APIs WG (public)" <public-webapi@w3.org>

> Cameron McCormack wrote:
> > This is probably not what browsers do in practice, though.  For example,
> > Opera 9 has an addEventListener method directly on the Node interface
> > prototype object


On 06/06/07, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> What Gecko does is to put all properties for all the interfaces an object
> implements onto the "closest" prototype object.  So if you have a <div>,
> HTMLDivElement.prototype will have all the properties the <div> is supposed to
> have defined directly on it.

Is this the reason for:

    var
        div=document.createElement('div'),
        span=document.createElement('span'),
        text=document.createTextNode('What am I?');
    Function.prototype.call.call(div.appendChild,span,text);
    text.data+='\r\n'+text.parentNode.tagName;

failing with an uncaught exception in Gecko but not in any other browser?

With the following modification it succeeds with matching behaviour to
Presto and WebKit:

    var
        dd=document.createElement('dd'),
        dt=document.createElement('dt'),
        text=document.createTextNode('What am I?');
    Function.prototype.call.call(dd.appendChild,dt,text);
    text.data+='\r\n'+text.parentNode.tagName;


If so, is there any possibility of making that work?
I can understand not allowing e.g. applying the same appendChild
implementation to work on both Element and Attr objects, but not
allowing it on other element objects seems a bit limiting to me.

> The prototype chain in Gecko basically follows the inheritance model in the DOM
> spec: HTMLDivElement.prototype.[[Prototype]] === HTMLElement.prototype, etc.
> Things like EventTarget are off to the side somewhere as in your imagined way to
> handle it.
>
> 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.

Is there any compelling reason why

    HTMLElement.prototype.appendChild === HTMLDivElement.prototype.appendChild

isn't true in Gecko? I.e. is there a good reason to not use the same
implementation of the function on all Element derived interfaces even
if it's located on different interface objects?

> 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?  How likely are UAs to rework the mappings between their native code
> and ECMAScript to follow said spec?

Well, I think developers are more interested in the prototype
hierarchy actually working for augmenting browsers as well as
Function.prototype.call and Function.prototype.apply actually working
on DOM methods in a natural way for ES than they are in any specific
prototype hierarchy.
-- 
David "liorean" Andersson
Received on Wednesday, 6 June 2007 09:26:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:57 GMT