One of the key changes is to the initial environment of modules, addressing the issue of module name capture pointed out a while back by Jasvir Nagra and Ihab Awad. The spec now distinguishes externally-loaded modules from internal modules. Internal modules simply extend the existing environment, like any other scoping construct. But to prevent external modules from being sensitive to all modules in scope, they are given an initial environment with only the local modules (i.e., the sibling modules declared in the same parent module as the module-load declaration in question). There are provisions for locally rebinding a module so that it can be made explicitly visible to an externally-loaded module.
The strawman now provides a more detailed semantics for the core system. Allen Wirfs-Brock made the good suggestion that we create a rationale document. I will be working on that, and I'll send announcement when it's ready. The module loaders API is not ready yet either, so that'll be another future announcement, too.
I've recently updated and clarified the draft strawman for simple modules:
http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules
One of the key changes is to the initial environment of modules, addressing the issue of module name capture pointed out a while back by Jasvir Nagra and Ihab Awad. The spec now distinguishes externally-loaded modules from internal modules. Internal modules simply extend the existing environment, like any other scoping construct. But to prevent external modules from being sensitive to *all* modules in scope, they are given an initial environment with only the *local* modules (i.e., the sibling modules declared in the same parent module as the module-load declaration in question). There are provisions for locally rebinding a module so that it can be made explicitly visible to an externally-loaded module.
The strawman now provides a more detailed semantics for the core system. Allen Wirfs-Brock made the good suggestion that we create a rationale document. I will be working on that, and I'll send announcement when it's ready. The module loaders API is not ready yet either, so that'll be another future announcement, too.
Dave
I've recently updated and clarified the draft strawman for simple modules:
One of the key changes is to the initial environment of modules, addressing the issue of module name capture pointed out a while back by Jasvir Nagra and Ihab Awad. The spec now distinguishes externally-loaded modules from internal modules. Internal modules simply extend the existing environment, like any other scoping construct. But to prevent external modules from being sensitive to all modules in scope, they are given an initial environment with only the local modules (i.e., the sibling modules declared in the same parent module as the module-load declaration in question). There are provisions for locally rebinding a module so that it can be made explicitly visible to an externally-loaded module.
The strawman now provides a more detailed semantics for the core system. Allen Wirfs-Brock made the good suggestion that we create a rationale document. I will be working on that, and I'll send announcement when it's ready. The module loaders API is not ready yet either, so that'll be another future announcement, too.
I've recently updated and clarified the draft strawman for simple modules: http://wiki.ecmascript.org/doku.php?id=strawman:simple_modules One of the key changes is to the initial environment of modules, addressing the issue of module name capture pointed out a while back by Jasvir Nagra and Ihab Awad. The spec now distinguishes externally-loaded modules from internal modules. Internal modules simply extend the existing environment, like any other scoping construct. But to prevent external modules from being sensitive to *all* modules in scope, they are given an initial environment with only the *local* modules (i.e., the sibling modules declared in the same parent module as the module-load declaration in question). There are provisions for locally rebinding a module so that it can be made explicitly visible to an externally-loaded module. The strawman now provides a more detailed semantics for the core system. Allen Wirfs-Brock made the good suggestion that we create a rationale document. I will be working on that, and I'll send announcement when it's ready. The module loaders API is not ready yet either, so that'll be another future announcement, too. Dave