Interesting ES5 side effect / window.hasOwnProperty(x) !== hasOwnProperty(x)
kangax at gmail.com
Mon Feb 7 11:37:38 PST 2011
What's the point of checking existence of method via such strict test? Why hasOwnProperty and not much more commonly used typeof console != "undefined", window.console, etc.
Is there even a guarantee of any kind that method in question (e.g. console) is an own property of window or global object? What if it's not? It seems very much possible for method to be defined further up in the prototype chain (e.g. Window.prototype) in which case there would be a false negative.
This isn't related to the original question, but this kind of check just doesn't look right in the first place.
Or am I missing something?
Sent from my iPhone
On Feb 7, 2011, at 1:54 PM, Wes Garland <wes at page.ca> wrote:
> I bumped into something this morning that I thought might be worth pointing out -- mostly because I was surprised to have seemingly-valid ES3 code break on an ES5 browser without strict mode in play.
> One of my developers has a habit of writing tests like
> if (!hasOwnProperty("console"))
> // supply my own console object instead
> This works fine on our deployment-target browsers, and up until very recently, on Firefox 4 betas. With the latest Firefox Minefield build, this same code throws a surprising (to me) error: "Error: can't convert undefined to object".
> If I understand the relevant Mozilla bug correctly (and I'm not sure that I do) -- https://bugzilla.mozilla.org/show_bug.cgi?id=619283 -- this is because of the way bindings are looked up in ES5 10.2.1.2.4.
> Comments? Obviously, the work-around is easy -- always invoke window.hasOwnProperty instead of hasOwnProperty -- but I wonder what other daemons lurk in the same corners.
> Wesley W. Garland
> Director, Product Development
> PageMail, Inc.
> +1 613 542 2787 x 102
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss