Accessing the global object

[Bob]

Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?

Thanks

[Joost Diepenmaat]

"Bob" <no****@nowhere.comwrites:

Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?

If you know the name of the global and you're sure you're not overriding
the name, you can use the global name.

IWO, yes and no.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[Peter Michaux]

On Feb 21, 5:10 pm, "Bob" <[e-mail]:

Is there anyway to access the global object from inside a function other
than doing a "var _global = this;" before declaring the function?

In a web browser the global object is usually available as a property
"window" of the global object. I think your idea of creating your own
"_global" is better. In ECMAScript 4 there will be a default "global"
property of the global object that references the global object. It
will work like "window" but "window" is a bad name when scripting in a
non-browser host.

Peter

[Richard Cornford]

Bob wrote:

Is there anyway to access the global object from inside a
function other than doing a "var _global = this;" before
declaring the function?

In javascript the value of the - this - keyword is determined by how a
function is called. If the function is not called as a method of an object
the value of the - this - keyword defaults to a reference to the global
object. As a result, from any context you can get a reference to the global
object using:-

function x(){
...
var localGlobalRef = function(){return this;}();
...
}

This is 100% reliable in ECMAScript 3rd Ed. implementations, and quite
useful, but it looks like ES 4 will not be back-compatible with ES 3 in this
regard. Still, not being back-compatible with ES 3 may (fingers crossed) be
enough to kill ES 4 in its cradle so maybe that is not worth worrying about.

Richard.

[Bob]

Interesting. Is there anyway to distinguish ES3 from ES4, and if ES4 is
present then return the global property?

Thanks very much
"Richard Cornford" <Ri*****@litotes.demon.co.ukwrote in message
news:fp*******************@news.demon.co.uk...

Bob wrote:

>Is there anyway to access the global object from inside a
function other than doing a "var _global = this;" before
declaring the function?

In javascript the value of the - this - keyword is determined by how a
function is called. If the function is not called as a method of an object
the value of the - this - keyword defaults to a reference to the global
object. As a result, from any context you can get a reference to the
global
object using:-

function x(){
...
var localGlobalRef = function(){return this;}();
...
}

This is 100% reliable in ECMAScript 3rd Ed. implementations, and quite
useful, but it looks like ES 4 will not be back-compatible with ES 3 in
this
regard. Still, not being back-compatible with ES 3 may (fingers crossed)
be
enough to kill ES 4 in its cradle so maybe that is not worth worrying
about.

Richard.

[AKS]

On Feb 22, 2:54 pm, "Richard Cornford" <[e-mail]>
wrote:

but it looks like ES 4 will not be back-compatible with ES 3 in this
regard. Still, not being back-compatible with ES 3 may (fingers crossed) be
enough to kill ES 4 in its cradle so maybe that is not worth worrying about.

Will be this compatible with ES4?

var localGlobalRef = (function () { return this; }).call(null);

[Thomas 'PointedEars' Lahn]

Peter Michaux wrote:

On Feb 21, 5:10 pm, "Bob" <[e-mail]:

>Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?

In a web browser the global object is usually available as a property
"window" of the global object.

Nonsense. You are jumping to conclusions.

I think your idea of creating your own "_global" is better.

See <47**************@PointedEars.de>, among others.

In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.

I am looking forward to that.

It will work like "window" but "window" is a bad name when scripting in a
non-browser host.

However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Peter Michaux]

On Feb 23, 5:37 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

On Feb 21, 5:10 pm, "Bob" <[e-mail]:

Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?

In a web browser the global object is usually available as a property
"window" of the global object.

Nonsense. You are jumping to conclusions.

The word "usually" usually indicates one is not making a definitive
conclusion.

I think your idea of creating your own "_global" is better.

See <[e-mail]>, among others.

In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.

I am looking forward to that.

It will work like "window" but "window" is a bad name when scripting in a
non-browser host.

However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?

this.opener

this.parent

this.frames

Peter

[Peter Michaux]

On Feb 24, 3:20 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Peter Michaux wrote:
On Feb 21, 5:10 pm, "Bob" <[e-mail]:
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.

The word "usually" usually indicates one is not making a definitive
conclusion.

The word "usually" implies a perceived majority of cases where said
condition would apply.

Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.

>In ECMAScript 4 there will be a default "global" property of the global
object that references the global object.
I am looking forward to that.

>It will work like "window" but "window" is a bad name when scripting in a
non-browser host.
However, how is the issue of accessing properties of the Global Object of
another global execution context going to to be addressed, as with frames
and windows?

this.opener

this.parent

this.frames

That would imply ECMAScript Edition 4 is going to standardize properties of
Window host objects as built-in properties of the Global Object

I don't see a problem. As far as I know, they aren't standardizing the
properties of the global object, they are simply standardizing a way
to access the global object that can be sensibly used in a non-browser
host.

[snip <--- look Thomas, I snipped]

By the way, http://pointedears.de/scripts/ is still an error page.

Peter

[Peter Michaux]

On Feb 24, 10:36 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
On Feb 21, 5:10 pm, "Bob" <[e-mail]:
Is there anyway to access the global object from inside a function
other than doing a "var _global = this;" before declaring the function?
In a web browser the global object is usually available as a property
"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.

Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.

Then I'm afraid your argument is a fallacious one indeed.

You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?

Peter

[Peter Michaux]

On Feb 24, 2:04 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

Peter Michaux wrote:

[...] Thomas 'PointedEars' Lahn [...] wrote:

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
>On Feb 21, 5:10 pm, "Bob" <[e-mail]:
>>Is there anyway to access the global object from inside a function
>>other than doing a "var _global = this;" before declaring the function?
>In a web browser the global object is usually available as a property
>"window" of the global object.
Nonsense. You are jumping to conclusions.
The word "usually" usually indicates one is not making a definitive
conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.

You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?

Your continuously missing the point,

If you clearly state your point then I will not miss it.

I stated that the overwhelming majority JavaScript hosts are web
browsers similar to NN4+ and IE4+. By this I also mean browsers like
IE7, FF2, etc. I am right. You seem to think I am wrong but you are
not able to identify these billions of JavaScript hosts that I should
consider. I would like to know to which billions of JavaScript hosts
you refer. They don't exist so you cannot do so. Instead you are
resorting to nitpicking about who has the burden of proof. Where are
your billions of hosts, Thomas? I'll even take hundreds of millions of
hosts if you can come up with those.

If you are trying to make some other point completely then I'm
interested what that is. There is no need to be so oblique about it.
Just say what you want to say in plain language. It cannot be so
difficult.

Peter

[Randy Webb]

Thomas 'PointedEars' Lahn said the following on 2/24/2008 5:04 PM:

Peter Michaux wrote:

>[...] Thomas 'PointedEars' Lahn [...] wrote:

>>Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Peter Michaux wrote:
>[...] Thomas 'PointedEars' Lahn [...] wrote:
>>Peter Michaux wrote:
>>>On Feb 21, 5:10 pm, "Bob" <[e-mail]:
>>>>Is there anyway to access the global object from inside a function
>>>>other than doing a "var _global = this;" before declaring the function?
>>>In a web browser the global object is usually available as a property
>>>"window" of the global object.
>>Nonsense. You are jumping to conclusions.
>The word "usually" usually indicates one is not making a definitive
>conclusion.
The word "usually" implies a perceived majority of cases where said
condition would apply.
Then I said what I meant. The overwhelming majority of JavaScript
hosts on earth are web browsers that have the global "window"
property.
Then I'm afraid your argument is a fallacious one indeed.

You've said things like this many times. As far as I know you have not
ever listed where these other billions of user agents are that are
not web browsers similar to IE4+/NN4+. Who/What/Where/Why/When/How are
they?

Your continuously missing the point, and making just more fallacious
arguments (here again: shifting the burden of proof), is becoming tiresome.

http://en.wikipedia.org/wiki/List_of_fallacies

You say they exist, someone else says they don't and asks you to prove
your argument. You don't and constantly whine about "shifting the burden
of proof". It is simple to prove what you say, just name a browser
without the window object being the global object. But no, you choose to
constantly whine about it and wonder why your credibility is at the
level it is.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Peter Michaux]

On Mar 2, 10:34 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[snip]

JFTR:http://wurfl.sourceforge.net/

So we have a maybe complete list of browsers used on mobile devices today.
However, that does not mean anything for tomorrow or user agents on other
devices.

So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.

But how to choose that limited set? I have never read anyone's
concrete rules for making this choice but I have read criticism of the
mainstream library writers for their choices.

If it still happens that the code breaks in a user agent and that becomes
known to the developer, then one should maybe add a branch for that user
agent. That decision depends of course mostly on the bug in the user agent
that caused it, if it could be worked around at all. If not, the UA is
broken and should not be supported.

"maybe"? "mostly"?

I agree this is all grey area but people are frequently derided for
their choices in the grey areas. When pressed for justification I
haven't seen the critics present anything concrete.

Is it ok for a developer to say "I know this script destined for the
general web is broken in Internet Explorer 5.5 and Opera 9 but I don't
care?" It seems as though he would be ripped to shreds and accused an
idiot on c.l.js but he would simply respond "Those browsers are not
supported". That doesn't seem sufficient to the critics that don't
have objective support for their own similar decisions.

Peter

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

Peter Michaux wrote:

>[...] Thomas 'PointedEars' Lahn [...] wrote:

>>So instead of having to check that list every day and update one's code
accordingly (which nobody could/would pay one for), one feature-tests for a
limited set of (in total) widely supported object models, including the
standardized one, and one will seldom have to change anything.

But how to choose that limited set? I have never read anyone's
concrete rules for making this choice but I have read criticism of the
mainstream library writers for their choices.

I think that if you support the W3C DOM, the MSHTML DOM, the Opera DOM,
Apple WebCore, the KHTML DOM, and the NS4 DOM, you can be pretty sure that
your application does not break on the mobile device. [...]

^^^^^^^^^^^^^^
That should have been "that you application works". Graceful degradation
and feature tests should prevent the application from breaking even if
exposed to an unknown DOM.
PointedEars

[VK]

<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.

[Peter Michaux]

On Mar 14, 10:30 am, VK <[e-mail]:

<snip>
All I want from you is the definition of the "feature detection". You
either can give it or you have no idea what are you talking about. I
am not answering your questions until I see that.

Did Richard not write the following?

<URL: http://www.jibbering.com/faq/faq_notes/not_browser_detect.html>

That should pretty much explain it for you.

Peter