2010/5/24 David Herman <dher...@mozilla.com> > > 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. >
Ok, got it. > > 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. > It isn't a concern of trusted vs untrusted modules as much as it is of change maintenance. If modules are to handle programming in the small, then this is a clear and sufficient improvement over modifying top-level bindings of the global object. But if (as I suspect) modules are meant to handle programming in the large, then module documentation is insufficient even for trusted parties or the very same author. The addition of "import Drawing" in my example even if it was accompanied by a documentation change in the Drawing module wouldn't cause _existing_ users of the Drawing module to realize something had changed in the api. 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. > Ok cool. Let me refresh myself on the module loaders API. I re-iterate - the question isn't one of trusted vs untrusted parties, its a question of programming in the large vs small. In a sufficiently large system, even trusted parties are equipped with sufficiently advanced cluelessness about other modules invariants that the line between malice and ignorance is blurred. Rather than create two different module mechanisms to deal with the two cases, if its possible for the same mechanism to deal with both cases, it ought to. I think your modules proposal is close to achieving this. If the module loader API handles this case, would you suggest the direct use of modules in small programs and insist on the module loader api for large programs? > > Dave > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
