So what I've got is we need static meta data for Module exports. For this reason "export" keyword is needed.
I was considering if these meta data could be given by the user of Module (instead of author of Module). If module file could only be used in ES6 (on need lexical convertion), I thinking most guys are not going to use this feature with in a very long time after ES6 released. These days I'm thinking about simply use proposal 2.(Allow importing multiple files as one module) We could easily make a wrapper for ES5 libs。 ------------------- // jQueryWrapper.js export var $; ------------------- ------------------- //in ***.html import "jQueryWrapper.js","jQuery.js" as jQuery; jQuery.$ ------------------- What do you think? 2012/9/26 Claus Reinke <claus.rei...@talk21.com> > I've looked at the Loader but it seems to be async? >> > > So far, yes, but previous discussions here led to the conclusion > that making the Loader functionality available for module syntax > imports would be useful and unproblematic. See, for instance, > the final paragraph of > > https://mail.mozilla.org/**pipermail/es-discuss/2012-**July/024184.html<https://mail.mozilla.org/pipermail/es-discuss/2012-July/024184.html> > > Perhaps that hasn't been worked into the spec yet. I hope it > doesn't get lost. > > > I know there are many ways to load multiple files together(iframe, >> XHR, script element and datauri for browser host) but what I'm >> suggesting is to make es6 module more friendly to es5 libraries. >> > > At first, a standard Loader plugin for treating ES5 scripts as modules > sounds useful, instead of everyone writing their own. Especially if a > generic script-as-modules-wrapper requires code analysis to figure > out global assignments. > > That, however, is exactly the issue: ES5 scripts are not friendly to > ES6 modularity, as all export information is encoded dynamically - > one cannot figure out the exports without running the code. > > So a general ES5-scripts-as-modules seems unlikely, and even > if one wanted to write converters for each currently encoded > module system, one would run into the runtime-vs-static issue, > unless all modules happen to use a static subset of current > module libraries (most module interface code will be static > in intention, if not in expression, but there are no guarantees). > > Which is why I was referring to the RequireJS approach of > encoding the expected exports in the wrapper configuration. > > Translating that to ES6 should be possible: we'd not even try > to extract the global assignments from the code automatically; > instead we'd tell the module wrapper manually how to extract > the expected exports from whatever the ES5 module code does > to its environment, by appending export declarations to the ES5 > code. At least, that is how I understand this approach;-) > > Claus > > I mean currently the es6 module grammar is using >> >> export var a; >> var b; >> var c; >> >> But why not export all top-level scope variables and let developers use >> IFFE to hide variables? >> >> var a; // export a automatically >> void function(){ >> var b; >> var c; >> }(); >> >> This will make libraries like old versions of jQuery work with es6 module >> without any code change. These libraries might be on CDN and changing >> their >> code will be a big cost in some scenarios. >> >> >> 2012/9/24 Alex Russell <a...@dojotoolkit.org> >> >> I think module loaders would, indeed help, although as you point out, >>> you're gonna need some sort of transformation step and we don't provide >>> an >>> AST to work against. You might need something like Traceur's front-end or >>> esprima to get started on a reliable transform pass. But yeah, doable. >>> >>> >>> On Mon, Sep 24, 2012 at 4:08 PM, Claus Reinke <claus.rei...@talk21.com>* >>> *wrote: >>> >>> >>>> Right. What I'm suggesting isn't that you'll be able to prevent the >>>> >>>>> global >>>>> from being augmented, rather that if your goal is to take an *already >>>>> well >>>>> behaved* library and wrap it with modules, that's possible. >>>>> >>>>> >>>> Aren't Module Loader Translation hooks meant to help with this? >>>> >>>> http://wiki.ecmascript.org/****doku.php?id=harmony:module_**<http://wiki.ecmascript.org/**doku.php?id=harmony:module_**> >>>> loaders#translation_semantics<**http://wiki.ecmascript.org/** >>>> doku.php?id=harmony:module_**loaders#translation_semantics<http://wiki.ecmascript.org/doku.php?id=harmony:module_loaders#translation_semantics> >>>> > >>>> >>>> >>>> Naïve idea: fetch the code, then add exports before evaluating the >>>> code as a local module scope. >>>> >>>> Though this would require parameterizing the Loader with some >>>> configuration data (export $ from jquery, export {f,g,x} from >>>> anotherES5utils, ..). Which seems to call for interaction between >>>> fetch and translate hooks, and possibly even between import >>>> declarations and loader hooks (how does the loader hook get >>>> to know which exports to add to an ES5 script, for a given import >>>> declaration?). >>>> >>>> RequireJS has some experience with wrapping non-modules >>>> via configuration options. >>>> >>>> https://github.com/jrburke/****requirejs/wiki/Upgrading-to-**<https://github.com/jrburke/**requirejs/wiki/Upgrading-to-**> >>>> RequireJS-2.0#wiki-shim<https:**//github.com/jrburke/** >>>> requirejs/wiki/Upgrading-to-**RequireJS-2.0#wiki-shim<https://github.com/jrburke/requirejs/wiki/Upgrading-to-RequireJS-2.0#wiki-shim> >>>> > >>>> >>>> >>>> Without a prototype implementation of modules as an executable >>>> spec, it will be difficult to find such edge cases and check how well >>>> they are covered in the existing semi-formal spec. >>>> >>>> Claus >>>> >>>> >>>> >>>> ______________________________****_________________ >>>> es-discuss mailing list >>>> es-discuss@mozilla.org >>>> https://mail.mozilla.org/****listinfo/es-discuss<https://mail.mozilla.org/**listinfo/es-discuss> >>>> <https://**mail.mozilla.org/listinfo/es-**discuss<https://mail.mozilla.org/listinfo/es-discuss> >>>> > >>>> >>>> >>> >>> >> > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
