Defining an implementation independent version of the global object in JavaScript

Question

I'm trying to define the global object in JavaScript in a single line as follows:

var global = this.global || this;

The above statement is in the global scope. Hence in browsers the this pointer is an alias for the window object. Assuming that it's the first line of JavaScript to be executed in the context of the current web page, the value of global will always be the same as that of the this pointer or the window object.

In CommonJS implementations, such as RingoJS and node.js the this pointer points to the current ModuleScope. However, we can access the global object through the property global defined on the ModuleScope. Hence we can access it via the this.global property.

Hence this code snippet works in all browsers and in at least RingoJS and node.js, but I have not tested other CommomJS implementations. Thus I would like to know if this code will not yield correct results when run on any other CommonJS implementation, and if so how I may fix it.

Eventually, I intend to use it in a lambda expression for my implementation independent JavaScript framework as follows (idea from jQuery):

(function (global) {
    // javascript framework
})(this.global || this);

Answer 1

this is in no way relevant to scope.

(function(){
    (function(){
        (function(){

            (function(){
            alert( this ); //global object
            })()

        }).bind({})()
    }).apply({})
}).call({})

this is only resolved during the call time of the function and comes down to few simple rules.

1. If the function is called as a property of some object, then that object will be this inside the function
2. If the function is called as is, this will be undefined so under non strict mode it will be the global object
3. If the function is called with .call/.apply then this is explicitly set by yourself.

So as you can see, it would fall under rule #2, which resolves to undefined. And since there is no "use strict";:

set the ThisBinding to the global object

Edit: I have now ran some quick tests in RingoJS and they infact put the "global object" inside the actual global object (as defined by standards) which is ModuleScope. Just because the actual global object in most js implementations has Object and String and so on, doesn't make an object global if it has those objects under it as well. The reason you can access String and Object in RingoJS is because they put them into the ModuleScope prototype:

var logs = require('ringo/logging').getLogger("h");

logs.info( Object.getPrototypeOf( this ) === this.global );
//true

Further proof that ModuleScope is the actual global object:

this.property = "value";
logs.info( property );
//"value"

So nothing is gained from this kind of trickery, it doesn't fix anything:

function injectGlobal(){
globalProperty = "value"; // "use strict" would fix this!
}

injectGlobal()

logs.info( globalProperty );
//"value"

Rant over, this refers to the actual global object already according to the rules given earlier in this post. this.global is not the real global object as defined by standards, it's just a container.

Additionally you could emulate this behavior in browsers:

Consider scopehack.js

this.global = window.global || top.global || {};

Consider main.html:

<script src="scopehack.js"></script>
<script>
this.global.helloWorld = "helloWorld"; //"global scope"
this.helloWorld = "helloWorld" //"ModuleScope"
</script>

<iframe src="module.html"></iframe>

And finally a "module" module.html:

<script src="scopehack.js"></script>
<script>
    with( this.global ) { //poor mans RhinoJS scope injection, doesn't work for writing
        console.log( helloWorld ); //"global scope" - "helloWorld"
        console.log( this.helloWorld ); //"ModuleScope" undefined
    }
</script>

Which one is an actual global object in both module.html and main.html? It is still this.

TLDR:

var obj = {
"String": String,
"Object": Object,
.....
};

Does not make obj the global object.

Answer 2

Implementation independant version is not trivial

(function (global) {
    // javascript framework
})(
   this && this.global || // ringoJS
   typeof root !== "undefined" && root || // node.js
   typeof global !== "undefined" && global || // more node.js
   typeof GLOBAL !== "undefined" && GLOBAL || // more node.js
   typeof window !== "undefined" && window || // browsers
   this // either undefined or some global default?
);

Your going to have to hard code in feature detection for every environment.

Answer 3

After reading Esailija and Raynos' answers I understood that my code this.global || this will not work for all cases in node.js; and that it may even fail in browsers if a variable called global already exists in the global scope.

Esailija pointed out that this.global is not really the global object, stating instead that this is the global object in RingoJS; and although I understand his arguments, for my purposes I require this.global and not this.

Raynos suggested that I hard code feature detection for every CommonJS environment. However since I'm currently only supporting RingoJS and node.js, I only need to test for global and window. Hence I decided to stick with this.global || this.

Nevertheless, as I said before this.global || this doesn't work for all cases in node.js as I understood from benvie's comments. In the node.js REPL I realized that I require this and not this.global. However, this.global || this expresses this.global. In a node.js module I require this.global and not this. However, it expresses this since this.global is undefined. Hence to solve this problem I finally decided to use the following code:

(function (global) {
    // javascript framework
})(typeof global !== "undefined" && global || this);

The reason I'm using this code is because in node.js modules this.global is undefined. Hence we must use global directly. Thus we use typeof global !== "undefined" && global to get the global object in both RingoJS and node.js; and we use this as the global object in browsers (window) and as a default fallback.

Note: I didn't provide any logic for finding the global object in the node.js REPL because I don't believe that my framework will be used directly within the REPL anyway. However, writing the logic to find it should be fairly trivial once one understands the complications of finding the global object in node.js as benvie pointed out. I know that I don't.