Import is currently used by Module. This way of using "import" looks like a loader feature.
2012/9/26 Russell Leggett <[email protected]> > On Tue, Sep 25, 2012 at 12:08 AM, 程劭非 <[email protected]> wrote: > >> Thanks, Claus and Alex, >> >> I've looked at the Loader but it seems to be async? >> >> 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. >> >> 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. >> >> > Why not simply the proposal a little. It would be nice to be able to > export top level etc. but I think there is a clear danger there. What if > instead of trying to make arbitrary scripts into modules, we just did the > loading, making sure the script was loaded before running the code that > depended on it. ES5 relies on global scope, and so would this. Instead of > allowing: > > import "jQuery1.3.2.js","MyModule.js" as MyModule; > > Maybe just allow something like: > > import "jQuery1.3.2.js" > import "MyModule.js" > > $(......).attr(......) > > Those scripts would still be executed in the global scope, and so this > module would be able to access $. It would be extremely easy to wrap this > way as well. Otherwise, you'd still need to worry about actually loading > the dependency, no? > > - Russ >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
