Understanding module and global scope
A common problem for browser-based applications is the global object, which is the top level scope shared by all scripts. If multiple scripts execute in the same context, they all run in the same top level scope. If they define top level variables with the same name, the last script wins. This is illustrated in the following diagram:
To work around this problem, various workarounds have been adopted, from using only a single global variable using a special name such as "$" or "_" to shunning the global scope all together by putting all code within closures.
Global and module scope in Ringo
Ringo solves this problem on a fundamental level by giving each module its own top level scope to run in. The global object is still there, but it's not in the scope chain. Instead, it is the prototype of all the module scopes, as illustrated in the following diagram:
As can be seen, the global object is no longer the place where variables are
allocated. Regardless of with or without
var, top level variables will be
created in the module's own scope. The global object with all the standard
objects such as
String is still there, though, providing
an environment that is totally compatible with the one found in browsers.