Re: Detecting the "type" of a DOM object

Le 21/06/2012 16:58, Boris Zbarsky a écrit :
> On 6/21/12 10:49 AM, David Bruant wrote:
>> Really? After check, yes indeed. That's excellent. I thought it wasn't
>> the case. I think what you said in your original message is what misled
>> me into thinking that:
>> "There's a common problem where someone has an object and they would
>> like to tell whether it's a Node (or an Array or a Date or whatever).
>> Right now, the way to do that is to use instanceof.... but with a huge
>> caveat: you have to pull the Node or Array or whatnot off the right
>> global object."
>> Apparently, this sentence was inaccurate for Node objects.
>
> I was talking about the state of things per the current ES and WebIDL 
> specs.  Implementation reality is a different issue; technically what 
> Gecko is doing right now is not WebIDL-compliant, and that's because 
> the implementation obviously predates WebIDL.
>
> And as I said, we're moving away from it because it makes it harder to 
> support other things WebIDL requires.  For example, right now in 
> Spidermonkey I can't make "n instanceof Node" work cross-global while 
> still having Function.prototype.toString.call(Node) return what WebIDL 
> requires it to return.  The new WebIDL bindings are making the latter 
> work at the expense of the former.
>
>> So in Firefox, instanceof can be used with browser API (DOM +
>> localStorage + XHR + whatev's is built-in to the browser)
>
> Stop right there.  ;)  XHR has been switched to WebIDL bindings 
> already (to ship in Firefox 14 in a few weeks), so you _can't_ use 
> instanceof there anymore.  Other things will be following.  Hence this 
> thread....
>
>> So it seems that the way Firefox model objects it's possible to detect
>> the type of any object, WebIDL or ECMAScript-based across globals, no?
>
> See above.
Hmm... This thread was started with the problem that a WebIDL-compliant 
does not allow to detect the "type" of an object cross-global.
Firefox does have a way to do it which is de-facto backward-compatible 
and you're planning to break it to be WebIDL compliant.
My analysis is that the use case is legitimate, that Firefox (who was 
here before WebIDL) has a good answer to it and that WebIDL should be 
revised rather than Firefox.


>> Of course. Then +1000 for changing how instanceof is defined in WebIDL
>> to adopt Gecko behavior!
>
> The point is WebIDL can't do that on its own: there is nothing in ES5 
> for it to hook into, as far as I know.  This needs coordination 
> between WebIDL and the ES spec.
Indeed.
How bad would it be to make an exception here for WebIDL to be 
implementable in ECMAScript terms?
Because enforcing WebIDL seems to have led to breaking a good Gecko 
feature for JS devs.


>> Interesting. I don't know whether this can be implemented with proxies
>
> I don't believe it can.
>
> I also don't believe that a proxy Node can be used to satisfy the 
> "Node must be a Function" requirements of WebIDL.
     var Node = new Proxy(function(){}, nodeHandler);

and then your Node constructor is a function. (I'm using the direct 
proxy http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies syntax).

The direct proxy proposal lists the things that can't be faked by the 
handler and instanceof is one of them.

David

Received on Thursday, 21 June 2012 15:31:22 UTC