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: Richard Cornford on 22 Feb 2010 12:32 On Feb 22, 5:03 pm, Lasse Reichstein Nielsen wrote: > kangax writes: <snip> > I can't find a way that's guaranteed to get you out of a > strict mode jail that tries to hide the global object. I assume you mean a way out that is not just not opting into strict mode, and so never being in the jail to start with. Richard.
From: Lasse Reichstein Nielsen on 22 Feb 2010 12:42 Jorge <jorge(a)jorgechamorro.com> writes: > On Feb 22, 5:37�pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> > wrote: >> Jorge <jo...(a)jorgechamorro.com> writes: >> > (globalObject).window === (globalObject).self === (globalObject) >> >> In IE8: >> �var global = function(){return this;}(); >> �global.window === global; �// => false >> >> Didn't help, sorry. >> (Might be a bug in ===, but it's still false :) > > Yes yes. And there are many many more odd things that are true -only- > in IEs. Are you saying that's the way it should be ? Are you -maybe- > advocating to standardize that behaviour ? Because if not, you'd > better think of it as just "another bug in IE". I'm not saying it should be like this, but neither am I saying in general terms how a non-standardized feature behaves, while ignoring how it actually works in one of the most common browsers. Eventually (perhaps) browsers will be HTML 5 compliant, with both a Window and a WindowProxy object (which is merely a codification of the way most browsers already work). Then it will be true that this.object = this in the global scope (but neither side is the global object :). /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Lasse Reichstein Nielsen on 22 Feb 2010 12:47 Richard Cornford <Richard(a)litotes.demon.co.uk> writes: > On Feb 22, 5:03 pm, Lasse Reichstein Nielsen wrote: > <snip> >> I can't find a way that's guaranteed to get you out of a >> strict mode jail that tries to hide the global object. > > I assume you mean a way out that is not just not opting into strict > mode, and so never being in the jail to start with. Yes, I mean a situation where I get to specify some code to be executed in a completely unknown context, and want to get hold of a reference to the global object. If the context turns out to be strict mode, and someone wants to block me, I can't see a way that can't be blocked. Which is probably a good thing for those who want a safe subset of ES :) /L -- Lasse Reichstein Holst Nielsen 'Javascript frameworks is a disruptive technology'
From: Thomas 'PointedEars' Lahn on 22 Feb 2010 13:18 kangax wrote: > Thomas 'PointedEars' Lahn wrote: >> kangax wrote: >>> 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" >> >> You have omitted the important part that immediately follows: >> >> | . In Edition 3, the variable and lexical environments of the caller >> | of an indirect e was used as the environments for the eval code. >> >> For this paragraph is part of the *informal* Annex E because that >> section > > The formal part is 10.4.2: > > 1. If there is no calling context or if the eval code is not being > evaluated by a direct call (15.1.2.1.1) to the eval function then, > > a. Initialize the execution context as if it was a global execution > context using the eval code as C as described in 10.4.1.1. > > [...] > > Let's see 10.4.1.1: > > The following steps are performed to initialize a global execution > context for ECMAScript code C: > > 1. Set the VariableEnvironment to the Global Environment. > 2. Set the LexicalEnvironment to the Global Environment. > > 3. Set the ThisBinding to the global object. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Fair enough. But that was _not_ what you were referring to, therefore not what I was referring to when I said >> I do not think you are understanding the Specification correctly. and therefore your > And I think you're not reading Specification carefully. is not justified. PointedEars -- var bugRiddenCrashPronePieceOfJunk = ( navigator.userAgent.indexOf('MSIE 5') != -1 && navigator.userAgent.indexOf('Mac') != -1 ) // Plone, register_function.js:16
From: Jorge on 22 Feb 2010 15:22
On Feb 22, 6:42 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> wrote: > Jorge <jo...(a)jorgechamorro.com> writes: > > On Feb 22, 5:37 pm, Lasse Reichstein Nielsen <lrn.unr...(a)gmail.com> > > wrote: > >> Jorge <jo...(a)jorgechamorro.com> writes: > >> > (globalObject).window === (globalObject).self === (globalObject) > > >> In IE8: > >> var global = function(){return this;}(); > >> global.window === global; // => false > > >> Didn't help, sorry. > >> (Might be a bug in ===, but it's still false :) > > > Yes yes. And there are many many more odd things that are true -only- > > in IEs. Are you saying that's the way it should be ? Are you -maybe- > > advocating to standardize that behaviour ? Because if not, you'd > > better think of it as just "another bug in IE". > > I'm not saying it should be like this, but neither am I saying in > general terms how a non-standardized feature behaves, while ignoring > how it actually works in one of the most common browsers. It's that I love to ignore *that* browser. Blatantly :-) > Eventually (perhaps) browsers will be HTML 5 compliant, with both > a Window and a WindowProxy object (which is merely a codification of > the way most browsers already work). Then it will be true that > > this.object = this this.object or this.window ? > in the global scope (but neither side is the global object :). It depends. What exactly would you expect a global object to be, when there are several different (JS) contexts ? You probably don't expect the next tab's global object to be the same... unless there's a parent-child relation: then the expectations suddenly change (subtly). And, what exactly would you expect a global object to hold ? Does it hold just the context's user-defined globals ? Does it hold the built-ins too ? But the same built-ins shared among contexts, or distinct separate instances ? If you mutate a global built-in, does it mutate the other contexts' built ins too ? These kind of things -for sure- ought to be established, specified and standardized. And I'm not sure that the fact that each window/frame/iframe/tab/ worker has its own JS context/global object contradicts the ES specs, when the specs are written for a single context, with just a single context in mind. Yes, each of these contexts has these "doors" to go to the others, but, how's that against the specs ? -- Jorge. |