On Tue, Jul 3, 2012 at 4:22 PM, Claus Reinke <[email protected]> wrote: >>> When reading Dave's post on "Static module resolution" [1], >>> the section on "Future-compatibility for macros" struck me >>> as a case where users/proponents of different module systems >>> seem to be talking past each other. All agree that there is an >>> important feature, but the approaches differ so much that the >>> common purpose may not be obvious. >> >> >> IMO this feature should be staged for addition after we get modules in ES. > > > Can we agree what the feature is, though? Macros are not > scheduled for this round, loader plugins are in current use > with requirejs/AMD, as is require.extensions in node. > > Looking closer at > > http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders > > there are interesting options for the Loader constructor, namely > the resolve, fetch and translate hooks. Those look as if the existing > features of current module systems could be emulated. An extended > loader could be chained with the system loader. > > However, I see two problems:
[problems snipped] There are two issues here. One is what code evaluated in nested loaders looks like. That's entirely up to the loader, but it certainly can use `import` and `export` and all of the other features of the module system. Those references are resolved by the loader being used. The second question is how we specify a particular loader to use. This is easy to do in JS code: `myLoader.load(url, callback)`. If we want convenient syntax for using this in a particular environment, then that would require an extension to the environment, such as an HTML declaration to use a particular loader for the rest of the page, or for a particular script tag. This is certainly doable, but requires coordination outside of TC39. -- sam th [email protected] _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
