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: David Mark on 21 Feb 2010 18:31 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> David Mark wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> David Mark wrote: >>>>>> [...] 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?) >>>> It is about writing a script that will work in non-browsers, as well as >>>> browsers. >>> [...] >>>> And yes, the OP did suggest declaring a global - window - >>>> variable and "calling it a day". :) >>> Granted, he did; however, I did not, and your suggestion is not any >>> better than his. >> Are you saying the OP is a nobody? :) > > Fallacy. The word "granted" should have given you some indication what my > reply was about. But I was necessarily replying to the previous assertion, which preceded your "granted" add-on (which didn't yet exist at the time of my reply). :) > >> And my primary suggestion was virtually identical to yours (save for an >> underscore in front of your global variable). > > But not what you made of it. What I made of it? > >> Now you are going on about an aside. > > Your fallacies in this matter are asides? Ah, maybe *that* is why I cannot > take them seriously. The part after:- var global = this; ....was clearly an aside and did not change the original suggestion, which was virtually identical to yours. > >>>>> 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. >>>> Of course it does. If we are dealing with a global - window - >>>> property, then we are dealing with something that is at least trying to >>>> look like a browser (and likely is a browser). >>> No. >> Whatever. Seems like an odd choice to define a global - window - >> property if you are not advertising at least some sort of browser-like >> compatibility. > > What do you consider "browser-like"? I think it is clear that I meant a host environment that featured a global - window - property. > >>>>> It is really apples and oranges. Whereas you have not even tried to >>>>> address the question which browsers you are actually talking about >>>>> here. All browsers. They've all got windows. ;) >>> No. >> Some browsers do not have windows? That would be news. > > See, even you can still learn something new here. LOL. A flute without holes is not a flute. > >>>>> 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. >>>> Yes, as mentioned, I didn't include any feature detection in the >>>> example. >>> Feature detection cannot remedy the intrinsic problem of this approach. >> But you cited its absence as one of your gripes. > > So what? So nothing. You are sapping my strength. > >>>>> 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? >>>> Same place that non-browsers get the "magic" setTimeout and setInterval >>>> methods. >>> Nonsense. >> There are documented cases of non-browsers with global >> setTimeout/setInterval methods and they work as you would expect them to >> work in browsers. > > What are those "non-browsers"? Search the archive. We've been over this a hundred times. IIRC, they were pointed out by Jim Ley in the early part of the century. I don't remember the details. Some Adobe product I think, but definitely not a Web browser. > >> So what are you trying to say? > > That you are still jumping to conclusions. Whatever. > >>>>> 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): >>>> That would be perfectly appropriate for an alert on the server. ;) >>> And you do not find that ambiguity of your code a little bit disturbing? >> Of course not. Where else would the message go on the server? Surely >> not to the display. ;) > > Then you are ready for a holiday. For a start, the browser-like alert() > displayed for the *user* to see it, sometimes execution even stops until > the user has *confirmed* it or closed the window it usually shows. I'm definitely ready for a holiday after this conversation. You may actually have a point about a server-side alert. But you were the one that suggested it might be logged to a file in the first place. > >>>>> 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'). >>>> It could, but that would be foolish on the part of the implementors. >>> No, it would not; how did you get that crazy idea after all, considering >>> >>> | It isn't up to a random environment to solve issues specific to your >>> | script. ;) >>> -- David Mark in <news:hlqbqi$l95$1(a)news.eternal-september.org> >>> >>> ? >> Apples and oranges. > > No. Hmm. I say yes. Not really an argument is it? > >> I was referring to the idea that all host environments should define a >> global - window - property. > > It isn't up to a random environment to satisfy your misconceptions about > what it is supposed to do either. Whatever. > >>> The implementation needs to satisfy the capabilities of the runtime >>> environment in which it is used; not the capabilities of some other >>> environment in which it is not used, only because some people jump to >>> conclusions about the availability of certain features. >> Right, so some environments may send the message to an LCD display or >> speak it or log it or whatever is appropriate. The point is that an >> alert method should be expected to convey a text message. > > No, it could be any message. But assuming a text message: Where would the > message be displayed, to whom, when, how? You are ignoring these aspects > completely. Enough with the speculation. The point is that there may well be an alert method in non-browsers and it is unlikely that it would vary wildly from the one found in browsers. > >>>>> Or it could take no arguments at all. >>>> That would make the least amount of sense for an - alert - method. >>> No, there could be general behavior that does not need an argument. >> Wouldn't be prudent. > > In your humble opinion. Or even my not so humble opinion. :) > >>>>> Or it could only be called under certain circumstances. Or ... And >>>>> then -- what? >>>> You are reaching. >>> No, you are. Browsers have nothing to do with non-browsers. That much >>> is self-evident. >> Yes, but there are always inferences involved with this stuff. You >> can't do much of anything without inferring something. > > You can do worse with inferring too much. Yes. > >>>>>>>> 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. >>>> There are no guarantees with this stuff. There never have been, even >>>> in browsers. You have to know your history, use sound feature >>>> detection and still things can go wrong. >>> Non sequitur. It is foolish to assume that things would work the same >>> everywhere. >> I think you are over-generalizing what I am saying. > > I have been pointing out to you the inevitable conclusion that you did not > want to see. I don't want to see any more of this conversation, that's for sure. :) > >>>>> 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. >>>> You can say the same thing about _browser_ host objects, yet viable >>>> cross-browser scripts are written every day (and have been for a >>>> decade). >>> Yes, cross-*browser*, limited to known implementations in browsers, >>> sometimes even only a set of known browsers. >> A set of known browsers would instead indicate a multi-browser script. > > After accepting this terminology, one must conclude that there is no such > thing as a cross-browser script, because we can only ever know a subset > of browsers. I think you are splitting hairs, but I've really lost interest in dissecting this any further. > >>> Implementations based on a common history of environments and >>> implementations, where some generally useful proprietary features became >>> de facto standards *for browsers*, and by that some even became >>> standards that are independent of the runtime environment or the used >>> programming language. >> Yes, and the implementors of the relatively rare non-browser host >> environments > > Why would they be rare? When? Where? *Relatively* rare, as compared to _browsers_. Enough.
From: Thomas 'PointedEars' Lahn on 21 Feb 2010 19:50 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>>> Thomas 'PointedEars' Lahn wrote: >>>>>> David Mark wrote: >>>>>>> [...] 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?) >>>>> It is about writing a script that will work in non-browsers, as well >>>>> as browsers. >>>> [...] >>>>> And yes, the OP did suggest declaring a global - window - >>>>> variable and "calling it a day". :) >>>> Granted, he did; however, I did not, and your suggestion is not any >>>> better than his. >>> Are you saying the OP is a nobody? :) >> Fallacy. The word "granted" should have given you some indication what >> my reply was about. > > But I was necessarily replying to the previous assertion, which preceded > your "granted" add-on (which didn't yet exist at the time of my reply). > :) You are not making sense. >>> And my primary suggestion was virtually identical to yours (save for an >>> underscore in front of your global variable). >> >> But not what you made of it. > > What I made of it? Your suggestion of using `this' was correct, of course; your conclusion what this would allow was not. >>> Now you are going on about an aside. >> Your fallacies in this matter are asides? Ah, maybe *that* is why I >> cannot take them seriously. > > The part after:- > > var global = this; > > ...was clearly an aside and did not change the original suggestion, > which was virtually identical to yours. In case you have not noticed, it is that part that the two of us are discussing here. >>>>> [...] If we are dealing with a global - window - >>>>> property, then we are dealing with something that is at least trying >>>>> to look like a browser (and likely is a browser). >>>> No. >>> Whatever. Seems like an odd choice to define a global - window - >>> property if you are not advertising at least some sort of browser-like >>> compatibility. >> >> What do you consider "browser-like"? > > I think it is clear that I meant a host environment that featured a > global - window - property. What you are saying does not make sense, so nothing you are saying can be clear. >>>>>> It is really apples and oranges. Whereas you have not even tried to >>>>>> address the question which browsers you are actually talking about >>>>>> here. >>>>> All browsers. They've all got windows. ;) >>>> No. >>> Some browsers do not have windows? That would be news. >> See, even you can still learn something new here. > > LOL. A flute without holes is not a flute. So a browser without windows is not a browser? >>>>>> 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. >>>>> Yes, as mentioned, I didn't include any feature detection in the >>>>> example. >>>> Feature detection cannot remedy the intrinsic problem of this >>>> approach. >>> But you cited its absence as one of your gripes. >> So what? > > So nothing. IOW, you do not really have a point here ... > You are sapping my strength. .... and you are trying to put the blame on others. But JFYI: It is not my fault that you do not have the stamina for a serious discussion. >>>>>> 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? >>>>> Same place that non-browsers get the "magic" setTimeout and >>>>> setInterval methods. >>>> Nonsense. >>> There are documented cases of non-browsers with global >>> setTimeout/setInterval methods and they work as you would expect them >>> to work in browsers. >> What are those "non-browsers"? > > Search the archive. I have asked *you*. Can you answer the question? > We've been over this a hundred times. So? > IIRC, they were pointed out by Jim Ley in the early part of the century. > I don't remember the details. Some Adobe product I think, but definitely > not a Web browser. That would be *one* non-browser. >>>>>> 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): >>>>> That would be perfectly appropriate for an alert on the server. ;) >>>> And you do not find that ambiguity of your code a little bit >>>> disturbing? >>> Of course not. Where else would the message go on the server? Surely >>> not to the display. ;) >> Then you are ready for a holiday. For a start, the browser-like alert() >> displayed for the *user* to see it, sometimes execution even stops until >> the user has *confirmed* it or closed the window it usually shows. > > I'm definitely ready for a holiday after this conversation. You may > actually have a point about a server-side alert. But you were the one > that suggested it might be logged to a file in the first place. That was only an example of possible behavior that, based on your faulty reasoning, *you* would not have considered. >>>>>> 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'). >>>>> It could, but that would be foolish on the part of the implementors. >>>> No, it would not; how did you get that crazy idea after all, >>>> considering >>>> >>>> | It isn't up to a random environment to solve issues specific to your >>>> | script. ;) >>>> -- David Mark in <news:hlqbqi$l95$1(a)news.eternal-september.org> >>>> >>>> ? >>> Apples and oranges. >> No. > > Hmm. I say yes. Not really an argument is it? "No." is only the first part of the argument. It continues as follows: >>> I was referring to the idea that all host environments should define a >>> global - window - property. >> It isn't up to a random environment to satisfy your misconceptions about >> what it is supposed to do either. > > Whatever. You have a peculiar way of saying "I am out of good counter-arguments". >>>> The implementation needs to satisfy the capabilities of the runtime >>>> environment in which it is used; not the capabilities of some other >>>> environment in which it is not used, only because some people jump to >>>> conclusions about the availability of certain features. >>> Right, so some environments may send the message to an LCD display or >>> speak it or log it or whatever is appropriate. The point is that an >>> alert method should be expected to convey a text message. >> No, it could be any message. But assuming a text message: Where would >> the message be displayed, to whom, when, how? You are ignoring these >> aspects completely. > > Enough with the speculation. It is not speculation, it is considering all possibilities, including possibilities that you do not want to see, because accepting them would make it obvious even to you that your logic is flawed. > The point is that there may well be an alert method in non-browsers and > it is unlikely that it would vary wildly from the one found in browsers. Because you say so? >>>>>> Or it could take no arguments at all. >>>>> That would make the least amount of sense for an - alert - method. >>>> No, there could be general behavior that does not need an argument. >>> Wouldn't be prudent. >> In your humble opinion. > > Or even my not so humble opinion. :) You do not have a point, and you do not want to admit that. So you are trying to make this discussion look ridiculous. >>>>>> Or it could only be called under certain circumstances. Or ... And >>>>>> then -- what? >>>>> You are reaching. >>>> No, you are. Browsers have nothing to do with non-browsers. That >>>> much is self-evident. >>> Yes, but there are always inferences involved with this stuff. You >>> can't do much of anything without inferring something. >> You can do worse with inferring too much. > > Yes. As you can accept that, is the logical conclusion not that one should infer as little as possible (about an unknown runtime environment) when programming? >>>>>>>>> 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. >>>>> There are no guarantees with this stuff. There never have been, even >>>>> in browsers. You have to know your history, use sound feature >>>>> detection and still things can go wrong. >>>> Non sequitur. It is foolish to assume that things would work the same >>>> everywhere. >>> I think you are over-generalizing what I am saying. >> I have been pointing out to you the inevitable conclusion that you did >> not want to see. > > I don't want to see any more of this conversation, that's for sure. :) There it is again, you are out of good counter-arguments, and you are trying to make this discussion look ridiculous to distract your readers from that fact. It will not work. >>>>>> 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. >>>>> You can say the same thing about _browser_ host objects, yet viable >>>>> cross-browser scripts are written every day (and have been for a >>>>> decade). >>>> Yes, cross-*browser*, limited to known implementations in browsers, >>>> sometimes even only a set of known browsers. >>> A set of known browsers would instead indicate a multi-browser script. >> After accepting this terminology, one must conclude that there is no >> such thing as a cross-browser script, because we can only ever know a >> subset of browsers. > > I think you are splitting hairs, *Me* splitting hairs, what an interesting idea. Who has introduced the difference between "cross-browser" (all) and "multi-browser" (some)? > but I've really lost interest in dissecting this any further. So you do see the problem with the idea of a "cross-browser script" after all? >>>> Implementations based on a common history of environments and >>>> implementations, where some generally useful proprietary features >>>> became de facto standards *for browsers*, and by that some even became >>>> standards that are independent of the runtime environment or the used >>>> programming language. >>> Yes, and the implementors of the relatively rare non-browser host >>> environments >> >> Why would they be rare? When? Where? > > *Relatively* rare, as compared to _browsers_. You have evaded answering the questions, but I am not surprised. You are evading the answers because that would make you think twice about your statements. > Enough. Agreed. This discussion is going nowhere as the arguments you had provided have been disproved, and as long as you or anybody else do not provide any new argument. 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 21 Feb 2010 20:50 Thomas 'PointedEars' Lahn wrote: > David Mark wrote: > >> Thomas 'PointedEars' Lahn wrote: >>> David Mark wrote: >>>> Thomas 'PointedEars' Lahn wrote: >>>>> David Mark wrote: >>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>> David Mark wrote: >>>>>>>> [...] 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?) >>>>>> It is about writing a script that will work in non-browsers, as well >>>>>> as browsers. >>>>> [...] >>>>>> And yes, the OP did suggest declaring a global - window - >>>>>> variable and "calling it a day". :) >>>>> Granted, he did; however, I did not, and your suggestion is not any >>>>> better than his. >>>> Are you saying the OP is a nobody? :) >>> Fallacy. The word "granted" should have given you some indication what >>> my reply was about. >> But I was necessarily replying to the previous assertion, which preceded >> your "granted" add-on (which didn't yet exist at the time of my reply). >> :) > > You are not making sense. Well, let me spell it out for you. You said nobody suggested it. I corrected you on that, _then_ you added the "granted" bit. So originally, it seems you had missed the fact the suggestion was made. That's the mistake I was referring to. Clear? > >>>> And my primary suggestion was virtually identical to yours (save for an >>>> underscore in front of your global variable). >>> But not what you made of it. >> What I made of it? > > Your suggestion of using `this' was correct, of course; your conclusion > what this would allow was not. Wrong. I made no conclusion about what that would allow. I added an aside about supporting browsers and non-browsers that feature common methods (e.g. alert, setTimeout). > >>>> Now you are going on about an aside. >>> Your fallacies in this matter are asides? Ah, maybe *that* is why I >>> cannot take them seriously. >> The part after:- >> >> var global = this; >> >> ...was clearly an aside and did not change the original suggestion, >> which was virtually identical to yours. > > In case you have not noticed, it is that part that the two of us are > discussing here. Yes, but you made a vague comment about my suggestion, which was only to declare a global that references the Global Object (as you also suggested, but with an underscore). > >>>>>> [...] If we are dealing with a global - window - >>>>>> property, then we are dealing with something that is at least trying >>>>>> to look like a browser (and likely is a browser). >>>>> No. >>>> Whatever. Seems like an odd choice to define a global - window - >>>> property if you are not advertising at least some sort of browser-like >>>> compatibility. >>> What do you consider "browser-like"? >> I think it is clear that I meant a host environment that featured a >> global - window - property. > > What you are saying does not make sense, so nothing you are saying can be > clear. That's about enough. Next topic.
From: Thomas 'PointedEars' Lahn on 21 Feb 2010 21:16 David Mark wrote: > Thomas 'PointedEars' Lahn wrote: >> David Mark wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> David Mark wrote: >>>>> Thomas 'PointedEars' Lahn wrote: >>>>>> David Mark wrote: >>>>>>> Thomas 'PointedEars' Lahn wrote: >>>>>>>> David Mark wrote: >>>>>>>>> [...] 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?) >>>>>>> It is about writing a script that will work in non-browsers, as >>>>>>> well as browsers. >>>>>> [...] >>>>>>> And yes, the OP did suggest declaring a global - window - >>>>>>> variable and "calling it a day". :) >>>>>> Granted, he did; however, I did not, and your suggestion is not any >>>>>> better than his. >>>>> Are you saying the OP is a nobody? :) >>>> Fallacy. The word "granted" should have given you some indication >>>> what my reply was about. >>> But I was necessarily replying to the previous assertion, which >>> preceded your "granted" add-on (which didn't yet exist at the time of >>> my reply). >>> :) >> >> You are not making sense. > > Well, let me spell it out for you. You said nobody suggested it. I > corrected you on that, _then_ you added the "granted" bit. So > originally, it seems you had missed the fact the suggestion was made. > That's the mistake I was referring to. And by posting "granted", I had already admitted that mistake. You are preaching to the choir here :) > Clear? As crystal. To you, too? >>>>> And my primary suggestion was virtually identical to yours (save for >>>>> an underscore in front of your global variable). >>>> But not what you made of it. >>> What I made of it? >> Your suggestion of using `this' was correct, of course; your conclusion >> what this would allow was not. > > Wrong. I made no conclusion about what that would allow. I added an > aside about supporting browsers and non-browsers that feature common > methods (e.g. alert, setTimeout). Based on your original suggestion, you presented code that was by your own account (and numerous failed attempts at justification later) supposed to fulfill the OP's requirement when it evidentially could not. That was your faulty conclusion (syn.: fallacy) I was referring to. >>>>> Now you are going on about an aside. >>>> Your fallacies in this matter are asides? Ah, maybe *that* is why I >>>> cannot take them seriously. >>> The part after:- >>> >>> var global = this; >>> >>> ...was clearly an aside and did not change the original suggestion, >>> which was virtually identical to yours. >> >> In case you have not noticed, it is that part that the two of us are >> discussing here. > > Yes, but you made a vague comment about my suggestion, which was only to > declare a global that references the Global Object (as you also > suggested, but with an underscore). No, I had intentionally quoted your suggestion down to the OR operation because that had been necessary to explain my "Ouch." (an uttering of pain IRL, used in Usenet to indicate that the person uttering it would find a suggestion from another person strongly inadvisable; it would not have made sense if I omitted the variable declaration or the faulty conclusions you made from it). So no, simply declaring a global variable was _not_ all of your suggestion. See above (or read the thread again, in particular <news:hlqbqi$l95$1(a)news.eternal-september.org> [your suggestion] and its follow-up <news:1956409.fDdHjke4Dd(a)PointedEars.de> [my first reaction to it]). PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: kangax on 22 Feb 2010 00:06
On 2/20/10 9:37 PM, Stoyan wrote: > Hi group, > > Since JS is everywhere (client, server, desktop...), it makes sense to > think how to write code that could run in environments other than the > one originally in mind. Perhaps it's not a good idea to use `window` > when the code could possibly run in environment that has no idea what > `window` is. > > so this pattern came to mind: > var global = function(){return this;}(); > However this apparently won't work in ES5 strict which aims to prevent > errors from calling constructors without `new` > > Another hacky idea is to call a function that assumes global when > `this` is unusable. Andrea Giammarchi came up with the shortest form > (http://twitter.com/WebReflection/status/9406207674) > var global = [].sort.call(null); > > The question is - is that ES5 strict-safe? Or any other ideas how to > get access to the global without hardcoding its name? > > Of course alternatively the new environment could simply define window > and problem is solved. E.g. if in some environment the global object > is called `foo`, then just do a global var window = foo; and call it a > day :) > > Thoughts? If I'm reading spec correctly, one of the ways to get global object from within _any_ code in ES5 is by using indirect call to eval. To quote Annex E from ES5: "indirect calls to the eval function use the global environment as both the variable environment and lexical environment for the eval code" This should mean that any indirect eval call should give you global object: .... var global = 1,eval('this'); // or: var x, global = (x=eval)('this'); // or: var global = 1&&eval('this'); // etc. .... -- kangax |