get the global object in any environment

[Thomas 'PointedEars' Lahn]

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.

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.

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.

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"?

Some browsers do not have windows? That would be news.

See, even you can still learn something new here.

But you cited its absence as one of your gripes.

So what?

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"?

So what are you trying to say?

That you are still jumping to conclusions.

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.

Apples and oranges.
No.

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.

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.

Wouldn't be prudent.

In your humble opinion.

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.

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.

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.

Yes, and the implementors of the relatively rare non-browser host
environments

Why would they be rare? When? Where?

have that history to consider.

No, because they are not implementing for browsers.

They'd be foolish to completely ignore it

and redefine things such as alert to - for example
- ignore the first argument and display the same message every time.

Instead, foolishly act people like you who assume that everything must work
the same everywhere, and those who would not make it so would be foolish.

And this is all academic anyway. Who actually writes such scripts? As
we know, context is everything and even generalized _browser_ scripts
are considered a bad idea, so the whole argument is out there.

Logical fallacy: Appeal to ridicule.


PointedEars

 

[David Mark]

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).

But not what you made of it.

What I made of it?

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.

What do you consider "browser-like"?

I think it is clear that I meant a host environment that featured a
global - window - property.

See, even you can still learn something new here.

LOL. A flute without holes is not a flute.

So what?

So nothing. You are sapping my strength.

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.

That you are still jumping to conclusions.
Whatever.


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.

No.

Hmm. I say yes. Not really an argument is it?

It isn't up to a random environment to satisfy your misconceptions about
what it is supposed to do either.
Whatever.


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.

In your humble opinion.

Or even my not so humble opinion.

You can do worse with inferring too much.
Yes.


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.

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.

Why would they be rare? When? Where?

*Relatively* rare, as compared to _browsers_. Enough.

 

[Thomas 'PointedEars' Lahn]

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.

What I made of it?

Your suggestion of using `this' was correct, of course; your conclusion
what this would allow was not.

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.

LOL. A flute without holes is not a flute.

So a browser without windows is not a browser?

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.

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.

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.

Hmm. I say yes. Not really an argument is it?

"No." is only the first part of the argument. It continues as follows:

Whatever.

You have a peculiar way of saying "I am out of good counter-arguments".

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 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.

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?

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.

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?

*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

 

[David Mark]

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?

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).

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.

 

[Thomas 'PointedEars' Lahn]

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?

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.

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:[email protected]> [your suggestion] and its
follow-up <news:[email protected]> [my first reaction to
it]).


PointedEars

 

[Thomas 'PointedEars' Lahn]

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
of ECMAScript Edition 5 describes features of Edition 5 that are
incompatible with Edition 3:

| Annex E
| (informative)
|
| Additions and Changes in the 5th Edition that
| Introduce Incompatibilities with the 3rd Edition

As a result, if your interpretation would be correct, the OP would be
writing incompatible code, and ISTM that the purpose of their question
was to write most compatible code instead.

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.
...

I do not think you are understanding the Specification correctly. `this'
is neither part of the variable environment nor of the lexical environment
of an execution context. (That it would be is the basis of the common
misconception of confusing `this' with scope.)


PointedEars

 

[Lasse Reichstein Nielsen]

(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
/L

 

[Lasse Reichstein Nielsen]

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.

Not if there is another variable called "eval" in scope.
If you are certain to have access to "eval" on the global object, you
are pretty close to haveing the global object itself.

Another approach is Function("return this")(), but Function may be
shadowed too, and Function.prototype.constructor is configurable,
so you're not guaranteed to be able to get to Function as
(function(){}).constructor.

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.
/L

 

[Jorge]

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".

 

[Richard Cornford]

kangax writes:

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.

 

[Lasse Reichstein Nielsen]

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 Nielsen]

On Feb 22, 5:03 pm, Lasse Reichstein Nielsen wrote:


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

 

[Thomas 'PointedEars' Lahn]

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

and therefore your

And I think you're not reading Specification carefully.

is not justified.


PointedEars

 

[Jorge]

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 ?

 

[Lasse Reichstein Nielsen]

But, AIUI, you can't have another variable named eval in strict mode

No, but you can create a shadowing binding before entering strict mode, e.g.,

// Non-strict context.
function myEval(s) { "use strict"; return eval(s); }
function shadower() {
var eval = myEval;
return function context(){
"use strict";
<< your code inserted here >>
}();
}
shadower();

That was my first thought as well, but from what I can see, this won't
"work". It looks like `Function('return this')()` won't give you a
global object.

True, my mistake. The function's scope will be the global environment,
but it will create a new scope when it's called, just as any other
function.

Or did I miss something?

No, not as far as I can see.


However, the Function constructor can create non-strict functions in
a strict environment, so this should work:

var global = Function("return function(){return this;}();")();

A determined jailer will be able to prevent that too, by changing
the binding of Function and Function.prototype.constructor:

var myFunction = function(oldFunction) {
var myFunction = function Function(args) {
var arr = Array.prototype.slice.call(args, 0, args.length);
arr[arr.length-1] = '"use strict";\n' + arr[arr.length-1];
return oldFunction.apply(null, arr);
};
Function.prototype.constructor = myFunction;
return myFunction;
}(Function);
function myEval(s) { "use strict"; return eval(s); }
function shadower() {
var eval = myEval;
var Function = myFunction;
return function() {
"use strict";
<< Your code, in jail >>
}();
}


I'm sure there are still holes in this (e.g., setTimeout with string
argument), but the idea is to prevent you from getting access to
running non-strict code in any way. That will also prevent you from
getting direct access to the global object.

You will actually need to shadow access to ANY non-frozen object on
the global object - because if "foo" refers to an property of the
global object, then
foo.bar = function() { return this; }
var global = foo.bar();
would work.

Strict mode is build so that you can't access strict mode variables
from non-strict code. You are still allowed to create non-strict code,
but only as if the code was running in the global environment.
/L

 

[Dr J R Stockton]

In comp.lang.javascript message <f249e211-5103-4933-8fc2-92740e661ba7@t3
1g2000prh.googlegroups.com>, Sat, 20 Feb 2010 18:37:37, Stoyan

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.

Evidently you cannot use any of the special properties of "window".

Do you really [always] need to access *THE* Global Object, or might it
be [sometimes] sufficient to create one with a known name, perhaps by
var glObj , and use it instead?