On Thu, Jan 14, 2010 at 1:58 PM, <[email protected]> wrote: > Hi Mike, > > On Thu, Jan 14, 2010 at 1:29 PM, Mike Samuel <[email protected]> wrote: >> Are these proposals mutually exclusive or complementary. >> If (1) and (2) are exclusive, is there a place to collect use cases >> for a module-off? > > For my part, I think (1) and (2) are counterproposals, but there may > exist a bunch of cross-pollination. For example, I will probably end > up stealing Kris's "import with" syntax sometime.
Are they really? The primitive proposal says: "This proposal specifies support for both “loading” dependencies as module factory functions (Makers) ..." I can see how the Makers will work, but I think to convince ourselves, it would be good to provide example #4 of implementing Makers on top of Context() (proposal 2 on top of proposal 1). I like the approach of providing a primitive Context() and then being able to implement Makers-style modules in those semantics (i.e. with pure JS code). For makers, what you're essentially proposing is "parameterized modules", no? The modules are parameterized by their dependencies. That is something I strongly support, but is unusual compared say Python or Ruby's module systems. In those systems, dependencies are essentially hard-coded. I think making this clear in the proposals is useful. Most of these papers are about this distinction (especially the Newspeak papers, and the Scala one): http://lambda-the-ultimate.org/node/3735 The way I think of it is that there are "bound" and "unbound" modules -- you bind the dependencies ("requires") of the Module by calling its module function with concrete dependencies. I've been working on some code which does allows this extra degree of flexibility for CommonJS modules: http://code.google.com/p/gelatin-js/ (needs docs, coming shortly) Basically you say require('file') in the source code. And then at build time, bind 2 different implementations to that "requirement", depending on where you want to deploy. You can think of this as "module metaprogramming at build time", whereas the makers proposal is module metaprogramming at runtime, in JavaScript. In one of the Newspeak papers he talks about not conflating "module definition" and "module configuration" (e.g. which Python/Ruby/Perl do). I agree with this -- there is one mechanism to define modules, and then you can configure the modules at build time or runtime. JavaScript especially needs this feature because there are so many different execution environments, and no standard library (yet). So I really like the general ideas of these 2 proposals, but some of the details are unclear. I think relating things to CommonJS modules is good because they are already implemented quite widely. thanks, Andy _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
