get the global object in any environment
in [JavaScript]
|
Prev: How do I get keys from an associative array?
Next: instructor's solutions manual for Basic Electromagnetics with Applications by Nannapaneni Narayana Rao
From: Thomas 'PointedEars' Lahn on 20 Feb 2010 23:29 David Mark wrote: > Why not just do this in the global context:- > > var global = this; > > ...and call it a day. :) > > That's what I did in My Library, which has no unqualified - window - > references. Come to think of it, it has no such _qualified_ references > either, which I don't consider ideal. So as not to assume that the > Global Object is the window object (despite the fact that it has been > observed to be in many browsers), ideally some of those references > should have been written:- > > (global.window || global) Ouch. PointedEars -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: David Mark on 20 Feb 2010 23:32 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Why not just do this in the global context:- >> >> var global = this; >> >> ...and call it a day. :) >> >> That's what I did in My Library, which has no unqualified - window - >> references. Come to think of it, it has no such _qualified_ references >> either, which I don't consider ideal. So as not to assume that the >> Global Object is the window object (despite the fact that it has been >> observed to be in many browsers), ideally some of those references >> should have been written:- >> >> (global.window || global) > > Ouch. And what do we consider to be painful about that? :) You snipped my disclaimer. (global.window || global).alert('Hello from any environment'); // see previous disclaimer If you simply use global.alert, you are assuming that - window - and the Global Object are the same thing (and I know you don't promote that assumption). So what's your line?
From: Thomas 'PointedEars' Lahn on 20 Feb 2010 23:57 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> Why not just do this in the global context:- >>> >>> var global = this; >>> >>> ...and call it a day. :) >>> >>> That's what I did in My Library, which has no unqualified - window - >>> references. Come to think of it, it has no such _qualified_ references >>> either, which I don't consider ideal. So as not to assume that the >>> Global Object is the window object (despite the fact that it has been >>> observed to be in many browsers), ideally some of those references >>> should have been written:- >>> >>> (global.window || global) >> >> Ouch. > > And what do we consider to be painful about that? :) You snipped my > disclaimer. Your disclaimer is nonsense. > (global.window || global).alert('Hello from any environment'); // see > previous disclaimer As is this. > If you simply use global.alert, you are assuming that - window - and the > Global Object are the same thing (and I know you don't promote that > assumption). Yes, you are, by this very construction. > So what's your line? Don't. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: David Mark on 21 Feb 2010 00:13 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> David Mark wrote: >>>> Why not just do this in the global context:- >>>> >>>> var global = this; >>>> >>>> ...and call it a day. :) >>>> >>>> That's what I did in My Library, which has no unqualified - window - >>>> references. Come to think of it, it has no such _qualified_ references >>>> either, which I don't consider ideal. So as not to assume that the >>>> Global Object is the window object (despite the fact that it has been >>>> observed to be in many browsers), ideally some of those references >>>> should have been written:- >>>> >>>> (global.window || global) >>> Ouch. >> And what do we consider to be painful about that? :) You snipped my >> disclaimer. > > Your disclaimer is nonsense. Is it? ISTM that if you declare a global - window - variable, you are going to screw it up. No? > >> (global.window || global).alert('Hello from any environment'); // see >> previous disclaimer > > As is this. I think not. A non-browser may well feature a global alert method, just as some have been demonstrated to feature a global setTimeout method, but no global window object. > >> If you simply use global.alert, you are assuming that - window - and the >> Global Object are the same thing (and I know you don't promote that >> assumption). > > Yes, you are, by this very construction. I don't think you understood what I was demonstrating. If there is a global window property (as in browsers), it will be used. If not, it will use the reference to the Global Object. Obviously, feature detection has been omitted from the example, but that doesn't seem to be your beef. > >> So what's your line? > > Don't. > I meant your line of _code_ for calling alert (or setTimeout or whatever) in an environment-agnostic fashion.
From: Thomas 'PointedEars' Lahn on 21 Feb 2010 01:08
David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>>> Why not just do this in the global context:- >>>>> >>>>> var global = this; >>>>> >>>>> ...and call it a day. :) >>>>> >>>>> That's what I did in My Library, which has no unqualified - window - >>>>> references. Come to think of it, it has no such _qualified_ >>>>> references >>>>> either, which I don't consider ideal. So as not to assume that the >>>>> Global Object is the window object (despite the fact that it has been >>>>> observed to be in many browsers), ideally some of those references >>>>> should have been written:- >>>>> >>>>> (global.window || global) >>>> Ouch. >>> And what do we consider to be painful about that? :) You snipped my >>> disclaimer. >> >> Your disclaimer is nonsense. > > Is it? ISTM that if you declare a global - window - variable, you are > going to screw it up. No? AFAIR, nobody suggested doing that. (And yes, you are going to screw up in the environments we know about. But this is about unknown environments, is it not?) >>> (global.window || global).alert('Hello from any environment'); // see >>> previous disclaimer >> >> As is this. > > I think not. A non-browser may well feature a global alert method, just > as some have been demonstrated to feature a global setTimeout method, > but no global window object. And if my grandmother had wheels, she'd be a motorcycle. See below. >>> If you simply use global.alert, you are assuming that - window - and >>> the Global Object are the same thing (and I know you don't promote that >>> assumption). >> >> Yes, you are, by this very construction. > > I don't think you understood what I was demonstrating. If there is a > global window property (as in browsers), it will be used. If not, it > will use the reference to the Global Object. Obviously, feature > detection has been omitted from the example, but that doesn't seem to be > your beef. Are you really asking what problems I have with this code? Well, I do not quite know where to begin. Missing feature detection is only one part of my criticism: A type- converting test involving an unknown potential host object and you can find nothing wrong with it? And have we not established by now that one does not grow reference worms, particularly not with method calls unless we know for sure that the MemberExpression left-hand side can evaluate to a fitting object reference, and particularly not if the code is exposed to unknown runtime environments? The other part is, of course, your readily jumping to conclusions here. First of all, you should rest assured you do not know *anything* about unknown environments (else they would not be unknown, would they?), so all your talk about "properties that are known to be specific to the window object in browsers" does not make any sense in that context. It is really apples and oranges. Whereas you have not even tried to address the question which browsers you are actually talking about here. Keep in mind that we are talking about a host object here, so it can have (and evidently has) different properties in different browsers, including those that you do not yet know. Then, if you assume that the two expressions refer to different objects instead of the same (else you would not need the OR operation in the first place), where did the global object of the other environment suddenly get the magic alert() method from? And that aside, why would you even expect such a method to work the same as the method defined for Window instances from a completely different runtime environment to begin with -- because the property has the same name? What does, for example, the implementor of an ECMAScript implementation for an e-book reader need to care what your favorite Web browser implements, and how it does that? Suppose, just suppose, it would work remotely the same as in that Web browser (i.e. it displayed a message to the user, and would not, e.g. log it to a file in the reader's filesystem -- or the book server's? -- instead): All things considered it could require, for example, a second argument to indicate the message title, a third for the message type aso., and throw a TypeError when those are missing (or `undefined'). Or the order of expected arguments could be reversed or interchanged. Or it could take no arguments at all. Or it could only be called under certain circumstances. Or ... And then -- what? >>> So what's your line? >> Don't. > > I meant your line of _code_ for calling alert (or setTimeout or > whatever) in an environment-agnostic fashion. As you can hopefully see by now, there can be no such thing. The very definition of "proprietary" precludes any reasonable assumptions about the availability or functionality of such features in runtime environments with ECMAScript binding that one knows nothing about. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |