> zero.js: > module One = load 'one.js'; > module Drawing = load 'gun.js'; > module JQ = load 'jquery.js'; > > one.js: > import JQ; > module Two = load 'two.js'; > > two.js: > import JQ; > import Drawing; > Drawing.draw(); > > The module of concern to us is one.js. According to your proposal, one.js is > doing in essence a text inclusion of the contents of two.js
It's not a textual inclusion. The only context-sensitivity within 'two.js' is its free references to other modules -- at the outset of the body of a module, only static module bindings are in scope. > and as a result is susceptible to the problems unhygienic macro expansion > suffers. That's an exaggeration and only very tangentially related. The point of module references is to strike a balance between clean separation and convenience. The ability to refer to other modules implicitly makes direct references possible (including cyclic references) while still providing the client with ultimate control over naming. > As a result, JQ in two.js gets bound to jquery which zero.js setup and one.js > imported as intended however Drawing *also* gets bound to the Drawing that > zero.js setup. The author of one.js - the importee that is responsible > setting up two.js - had no way of knowing that two.js needed Drawing and was > going to find one in the scope chain. I'm not sure what you mean by "no way of knowing." In this setup, a module's free references to existing modules are part of its API. This information would be part of the documentation. It's similar to the way things work now, in that libraries collaborate by sharing things through documented top-level bindings in the global object, but done in a more static way to allow for true lexical scope. > Nor could it take any action to withholding bindings to other imports deeper > in modules that two.js may request. On the contrary-- it can, via module loaders. If you want to load, say, an untrusted 3rd party module, you can use module loaders to do so in a separate environment. But the purpose of the core module system is not to provide isolation between untrusted parties. It's important to distinguish modularity and isolation. The module system provides cleaner code separation while preserving convenient collaboration between modules. The module loaders API, by contrast, provides stronger controls for isolation. Dave _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
