domenic at domenicdenicola.com (2013-08-02T21:02:59.071Z)
Actually, if module statements are not allowed at all within imported modules, this invalidates the example, which is the most important use case for module statements. Basically it would be impossible to load the module declarations for a modules dependencies in the same request as an import request to the module itself. Surely this is the most fundamental use case for modules providing the multiplexing support of dependencies?
Actually, if module statements are not allowed at all within imported modules, this invalidates the example, which is the most important use case for module statements. Basically it would be impossible to load the module declarations for a modules dependencies in the same request as an import request to the module itself. Surely this is the most fundamental use case for modules providing the multiplexing support of dependencies? Guy On 31 July 2013 10:53, Guy Bedford <guybedford at googlemail.com> wrote: > Ok sure, while I understand nesting is no longer supported, it could > potentially still make sense in terms of defining the module being an > operation. > > Consider as an equivalent to the example the following: > > foo.js: > System.set('foo', new Module({ > p: 'value' > })); > System.set('foo/dependency', new Module({ > q: 'dep' > })); > > main.js: > System.import('foo'); > > The question was specifically if foo would be an empty module, or the > defined module in this case. With the current spec it would be an empty > module. > > This is fine though, the work around as you say is to use exports for the > exact module name being built. Future build tools would need to take this > into consideration. Glad to have this clarified though. > > Guy > > On 31 July 2013 04:53, Sam Tobin-Hochstadt <samth at cs.indiana.edu> wrote: > >> I think one of us is confused here. How are you importing from >> 'foo.js'? If you're importing from it, expecting that it's the body of >> a module, then you'll get a syntax error -- modules don't nest. >> >> You could configure the loader so that it treats 'foo.js' as >> containing the definition of the 'foo' module plus other modules, in >> which case this works fine but there's no empty module at all. >> >> Sam >> >> On Wed, Jul 31, 2013 at 3:05 AM, Guy Bedford <guybedford at googlemail.com> >> wrote: >> > I'm in the process of matching up an ES6 module loader with AMD support >> to >> > the RequireJS tests, and have a question on concatenated module files. >> > >> > If I have a module, foo.js, which defines its own name and its >> dependencies: >> > >> > foo.js: >> > module 'foo' { >> > export var p = 'value'; >> > } >> > module 'foo/dependency' { >> > export var q = 'dep'; >> > } >> > >> > When loaded, will this ensure that the module value is defined from the >> > module statement taking precedence over the empty module implied by the >> lack >> > of exports? >> > >> > These techniques are used extensively for builds in RequireJS, which I >> think >> > would be very useful in ES6 modules and for the AMD polyfill path. >> > >> > Clarification would be appreciated to know if I'm correct in including >> this. >> > >> > Guy >> > >> > _______________________________________________ >> > es-discuss mailing list >> > es-discuss at mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/d0ac0f04/attachment.html>