Re: Detecting the "type" of a DOM object

On Jun 21, 2012, at 7:49 AM, David Bruant wrote:

> Le 21/06/2012 16:30, Boris Zbarsky a écrit :
>> On 6/21/12 4:15 AM, David Bruant wrote:
>>> Le 21/06/2012 07:30, Boris Zbarsky a écrit :
>>>> Alternately, we could try to make instanceof actually work cross-global?
>>> +1, but eternal web worry: won't it break the web?
>> 
>> It works cross-global for DOM objects in Gecko right now.
> 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.
> 
> So in Firefox, instanceof can be used with browser API (DOM + localStorage + XHR + whatev's is built-in to the browser) objects to know what "type" is an object and for Array and Date and other ECMAScript objects, checking the [[Class]] property can reliably be used across globals.
> 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?
> 
>> We're actually deliberately breaking that in the WebIDL bindings at the moment, so the actual web compat breakage for us is in the other direction: as we move to WebIDL with its stricter instanceof sites might break.
> Of course. Then +1000 for changing how instanceof is defined in WebIDL to adopt Gecko behavior!
> 
> 
>>> I assume that by making instanceof work globally you mean breaking its
>>> definition based on prototype object identity?
>> 
>> Yes.  In Spidermonkey there is a hook that can be attached to a given [[Class]] that will get called if the object is the RHS of instanceof and can do whatever it wants.  In the case of current DOM objects it just checks whether the object implements the given interface, for example.
> Interesting. I don't know whether this can be implemented with proxies (for which one use case is to be able to implement the browser APIs in pure JS). I'll think about it.

[[HasInstance]] [1], [2] has always been an internal method that,in theory, is over-rideable  by host object implementations.  So, what FF is doing for instanceof has always been legal.  The proxy spec. [3] currently doesn't allow over-riding [[HasInstance]].  I'll have to talk to Tom to find out why. That seems inconsistent with the overall goal of using Proxies to implement existing host object semantics.

However, please step back a bit.  Does it really make sense for the built-in JavaScript instanceof operator to work different for Web API objects then it does for user defined objects or objects defined by other libraries.  That's the sort of inconsistency that drives web developers crazy.  To web developers, it's just all JavaScript. It's fine if we need to enhance JS to support a broader set of use cases.  But it would be a bad idea to define new semantics that only apply to Web API objects.

Allen

[1] http://ecma-international.org/ecma-262/5.1/#sec-11.8.6 
[2] http://ecma-international.org/ecma-262/5.1/#sec-15.3.5 
[1] http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#api 





> 
> David
>