function require (__filename) {
return function ( ) { eval(File.read(__filename)); }( );
}
Aristid Breitkreuz
All context layers in javascript use this; why should the top level
context be different? Why introduce a new keyword. I'd rather view
module files as constructor functions for objects.
Also many browser scripts today can be immediately used with the
module system if "this" is used instead of "exports":
http://www.json.org/json2.js
http://jqueryjs.googlecode.com/files/jquery-1.3.2.js
Because of the bizarre behavior
associated with "this" in JS, several secure JS subsets (ADsafe,
Cajita, perhaps dojox secure?) ban it. Others (Jacaranda) severely
restrict its use.
exports will neither become reserved in any way, nor is it. It's just a
variable that is part of the securable modules API. (However, export
without s is a reserved word.)
It's funny that you should mention jQuery. I wasn't aware that they
had finally shifted from using "window" directly to using "this". I
made this recommendation two years ago so that you could make this
argument today ;-) http://dev.jquery.com/ticket/1794.
Ihab and I also recommended that "this" be a synonym for "exports" to
support a migration phase where modern day scripts could also be used
as modules. The rationale is described in the section "Global/Salty
Script/Module" in "Importing Capabilities and Exporting a Module" in
our proposal to ECMA
http://docs.google.com/Doc?id=dfgxb7gk_34gpk37z9v&hl=en
However, "exports" is a better way to refer to explicitly denote
exported stuff for a couple reasons. For one, it would resemble our
intended syntax in a future ECMAScript standard, "export foo" being
sugar for "exports.foo". It also provides a name by which exports can
be referenced in /any/ nested scope; using "this" is a hazard in those
scope because it can be subverted by a third-party function caller.
Also, for the reasons Mark outlines, "this" is banned in most security
contexts, so to be interoperable, a module must not use "this" and
therefore must use the term "exports".
Also, the use of "exports" is not going to cause the same difficulties
as reserved keywords in the language. It is not a keyword, so you can
reassign it, declare variables by the same in inner scope, and any of
the other freedoms we as JavaScripters enjoy. A script may blissfully
use the term without knowledge that it's already in scope. Thankfully
"export" and "import" are reserved keywords, since we would like to
repurpose them in the future for "exports" and "require" sugar and
would not have such an opportunity otherwise.
While I am strongly in favor of providing a migration phase for modern
scripts, we as application programmers tend to do anything that works
and suits our fancy without regard or awareness of the tradeoffs, such
that if "this" is permitted to be used to refer to exports, it
certainly will be abused. For those that care, Chiron still permits
the use of "this" as a synonym for "exports" so that global scripts
can migrate for the time being, and I feel that addressing this issue
only in a client-side loader is sufficient and there need not be a
resolution by this group either requiring or disallowing the use of
"this" as a synonym of "exports".
Kris Kowal
Ihab and I also recommended that "this" be a synonym for "exports" to
support a migration phase where modern day scripts could also be used
as modules.
If you just take the module file and wrap it in a constructor then it would
function require () {
return new function () { (module code) }
}
exports.foo = function () {
return "foo";
}
exports.submodule = new function () {
function private () {
return "private";
}
this.hello = function () {
return "hello " + private();
};
};
Later the programmer decides that submodule should be in its own file.
The programmer creates a directory module/ and a file
module/submodule.js. Now he is faced with the task of renaming
"this.hello" to "exports.hello". Obviously this is not a huge problem
but it demonstrates that "this" is natural to export objects out of
the scope.
I didn't explain myself well. I wasn't suggesting modules rewrite the
require function, rather I was suggesting that the data in a module
file be thought of the body of a constructor function. When viewed
this way, "this" is the natural a scope exporter.
> 4. You seem to be making the assumption that modules usually supply a single
> class, rather than a group of related things. I don't believe that is a
> reasonable assumption.
No..? Or maybe I miss understand you. For example:
var module = new function () {
function PrivateClass () { /* ... */ }
this.PublicClass1 = function () { /* ... */ };
this.PublicClass2 = function () { /* ... */ };
};
misunderstand *facepalm*