-
Notifications
You must be signed in to change notification settings - Fork 2
Modules
Stability: 3 - Stable
promiseLand assumes that a module loader is in use. promiseLand modules are compatible with commonjs as well as AMD style loaders.
simply use return in the main scope to define the export of the module.
// content of somefile.pland
var private = "some private module variable"
// the export:
return {
gimme: function(){
return private;
}
};
// execution ends at return (ofc)
// just want to be thorough - sorry for being boring
code.that.is.never.executed();
a compatibility subset for usage without a module loader exists, but it is uncertain at this point if it will be continued.
require is a keyword in promiseLand.
syntax:
require expression
the whole thing is called an require expression.
require expressions are asynchronous(!).
functions using require expressions will return in a promise.
a require expression on module scope will cause the module to export a promise.
asynchronous expressions on module scope will cause the module to export a promise.
lets call those modules asynchronous modules.
require expressions of asynchronous modules do not have to be dereferenced.
promiseLand keeps track of asynchronous modules. Since a require expression is asynchronous in the first place its possible to make the usage of asynchronous modules transparent in promiseLand.
in short: you dont need to care about weather a module is asynchronous or not.
promiseland defines all variables that are in use on the module scope and tries to initialize them with the content of the global variable of that name.
no error will be thrown if there is no global variable defined.
note: This seemed neccessary to make a clear distinction between promiseLand and ecmaLand.
it also comes in very handy when checking for global variables that may not exist or implicityly declaring variables.
Another good sideeffect is that you can not declare any global variable.
found any errors?
missing something?
let me know