API to identify host objects
Irakli Gozalishvili wrote:
Lately I have being struggling with an implementation differences of host (DOM) objects across the browsers. So far only reliable way I could find to identify host objects is by a following assertion:
object.constructor.call === void(0)
Wow, that's not bad (except for the overparenthesized 0 :-P).
Behaviour seems to be consistent across FF, Opera, Safari, and Chrome (Don't have windows to test on IE). I think it would be great if there was some standardised way to identify host objects.
There does seem to be some fuzzy need, but given jQuery's isPlainObject (api.jquery.com/jQuery.isPlainObject) the way people check varies.
My personal use case is polymorphic method dispatch library Gozala/method that has same semantics as clojure protocols. Method implementations for host objects and built-ins are stored in the separate dictionary to avoid memory leaks and to support objects from diff JS contexts / frames / compartments.
Doesn't the latter (cross-frame/etc.) need affect native objects too?
On Mon, Nov 12, 2012 at 2:12 PM, Irakli Gozalishvili <rfobic at gmail.com>wrote:
Lately I have being struggling with an implementation differences of host (DOM) objects across the browsers. So far only reliable way I could find to identify host objects is by a following assertion:
object.constructor.call === void(0)
Behaviour seems to be consistent across FF, Opera, Safari, and Chrome (Don't have windows to test on IE). I think it would be great if there was some standardised way to identify host objects.
My personal use case is polymorphic method dispatch library Gozala/method that has same semantics as clojure protocols. Method implementations for host objects and built-ins are stored in the separate dictionary to avoid memory leaks and to support objects from diff JS contexts / frames / compartments.
If you know of a better of identifying host objects I would really love to know that too.
In ES5, if Object.prototype.toString.call(obj) indicates any of the std [[Class]] values for so-called "native" objects, then obj must be a native object. Else, obj must be a so-called "host" object. (I will be so happy once we're past that terminology!)
-- Irakli Gozalishvili Web: www.jeditoolkit.com
On Monday, 2012-11-12 at 14:30 , Brendan Eich wrote:
Irakli Gozalishvili wrote:
Lately I have being struggling with an implementation differences of
host (DOM) objects across the browsers. So far only reliable way I could find to identify host objects is by a
following assertion:object.constructor.call === void(0)
Wow, that's not bad (except for the overparenthesized 0 :-P).
Behaviour seems to be consistent across FF, Opera, Safari, and Chrome
(Don't have windows to test on IE). I think it would be great if there was some standardised way to
identify host objects.There does seem to be some fuzzy need, but given jQuery's isPlainObject
(api.jquery.com/jQuery.isPlainObject) the way people check varies.My personal use case is polymorphic method dispatch
library Gozala/method that has same semantics as clojure protocols. Method implementations for host objects and
built-ins are stored in the separate dictionary to avoid memory leaks
and to support objects from diff JS contexts / frames / compartments.Doesn't the latter (cross-frame/etc.) need affect native objects too?
Yes it does and method implementations for built-ins are also stored in a separate hash. Detecting built-ins seems to be a lot easier though since Object.prototype.toString.call(value) returns "[object Error]", "[object Number]", … etc...
Lately I have being struggling with an implementation differences of host (DOM) objects across the browsers. So far only reliable way I could find to identify host objects is by a following assertion:
object.constructor.call === void(0)
Behaviour seems to be consistent across FF, Opera, Safari, and Chrome (Don't have windows to test on IE). I think it would be great if there was some standardised way to identify host objects.
My personal use case is polymorphic method dispatch library Gozala/method that has same semantics as clojure protocols. Method implementations for host objects and built-ins are stored in the separate dictionary to avoid memory leaks and to support objects from diff JS contexts / frames / compartments.
If you know of a better of identifying host objects I would really love to know that too.
-- Irakli Gozalishvili Web: www.jeditoolkit.com