This term defineModule makes sense if the act of 'defining' a module
in an environment is considered from the module user perspective. Fits
in with the meta-api approach.
The parameters of the proposed require() function are subsumed into the properties of the object passed to defineModule(). Maybe defineModule() - if implemented natively - can offer the 'hermetic eval' sandbox functionality that module dev's are after. Syntax sugar - import mymod; - can be implemented with macros.
Also, if a list of module url's (and strings/ast's) could be passed to
defineModule() then maybe a shared 'global' environment could be
passed as well:
// with destructuringconst [mymod, mymod1] = Object.defineModule({
url:[...,...],
env:"http://www.acme.com/myglobal.js"
})
For ES6 syntax/semantics re modules how about:
const mymod = Object.defineModule({
url: "http://www.acme.com/mymod.js",
otherProp: "...",
...
});
Or if the module source is a string of ES code:
var mymod_str = "var x = 4; ...";
const mymod = Object.defineModule({
source: mymod_str,
otherProp: "...",
...
});
Or if the module is an AST (JsonML?):
var mymod_ast = ["Program", [ ... ]];
const mymod = Object.defineModule({
ast: mymod_ast,
otherProp: "...",
...
});
This term 'defineModule' makes sense if the act of 'defining' a module
in an environment is considered from the module user perspective. Fits
in with the meta-api approach.
The parameters of the proposed require() function are subsumed into
the properties of the object passed to defineModule(). Maybe
defineModule() - if implemented natively - can offer the 'hermetic
eval' sandbox functionality that module dev's are after. Syntax sugar
- import mymod; - can be implemented with macros.
Also, if a list of module url's (and strings/ast's) could be passed to
defineModule() then maybe a shared 'global' environment could be
passed as well:
// with destructuring
const [mymod, mymod1] = Object.defineModule({url:[...,...], env:
"http://www.acme.com/myglobal.js" })
For ES6 syntax/semantics re modules how about:
const mymod = Object.defineModule({ url: "http://www.acme.com/mymod.js", otherProp: "...", ... });
Or if the module source is a string of ES code:
var mymod_str = "var x = 4; ..."; const mymod = Object.defineModule({ source: mymod_str, otherProp: "...", ... });
Or if the module is an AST (JsonML?):
var mymod_ast = ["Program", [ ... ]]; const mymod = Object.defineModule({ ast: mymod_ast, otherProp: "...", ... });
This term
defineModule
makes sense if the act of 'defining' a module in an environment is considered from the module user perspective. Fits in with the meta-api approach.The parameters of the proposed
require()
function are subsumed into the properties of the object passed todefineModule()
. MaybedefineModule()
- if implemented natively - can offer the 'hermetic eval' sandbox functionality that module dev's are after. Syntax sugar -import mymod;
- can be implemented with macros.Also, if a list of module url's (and strings/ast's) could be passed to
defineModule()
then maybe a shared 'global' environment could be passed as well:// with destructuring const [mymod, mymod1] = Object.defineModule({ url:[...,...], env:"http://www.acme.com/myglobal.js" })