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

Re: Prototype chain for objects that implement multiple interfaces

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 08 Jun 2007 16:34:47 -0500
Message-ID: <4669CB77.3020405@mit.edu>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

liorean wrote:
> 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?

"Somewhat"  ;).

It's all part and parcel of the way XPConnect maps things back and forth from 
C++ to JavaScript in Gecko.

>        dd=document.createElement('dd'),
>        dt=document.createElement('dt'),

That's a side-effect of the fact that both of those use the same concrete class 
at the moment.    The same one as <span>, in fact.

> If so, is there any possibility of making that work?

Not in the current setup in Gecko.

> 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 point is that the system doesn't know that the appendChild comes from 
Element.  All it knows is that a member method of one class is being applied to 
another one, and that it doesn't allow that.  As things stand, that is.

> Is there any compelling reason why
>    HTMLElement.prototype.appendChild === 
> HTMLDivElement.prototype.appendChild
> isn't true in Gecko?

Define "compelling"?  The basic reason is that this is how the generic JS-to-C++ 
mapping layer works.  Changing how it works is not really much of an option for 
compat and time reasons; the only quick way forward is to stop using it 
altogether for DOM objects.  Which might happen.

Received on Friday, 8 June 2007 21:34:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:23 UTC