What does it look like if you want to import more than one variables from one module?
2012/8/31 Shijun He <[email protected]>: > On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 <[email protected]> wrote: >> I guess Kevin has some same concerns with me. >> >> The four things point to one question: What should we do with the old >> ES3/ES5 libraries after we have module? >> (please correct me if you didn't mean that.) >> >> ES3/ES5 libraries might be in more than one files and there are no >> “export” and "import" in it. >> >> For example, I might want to use jQuery 1.3.2 in ES6, and I might >> could not modify the .js file for some reason. >> >> I might want the following thing: >> --------------------------------- >> import "http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"; >> as jQuery >> var $ = jQuery.$; >> --------------------------------- > > I'm using this pattern from 2006: > > $import("jquery.min.js#jQuery,$") > > translate to ES6 syntax: > > import {$} from "jquery.min.js#jQuery" > > > That is, use URI fragment to identify the export names for old scripts. > The loader will run the scripts in a sandbox and only export the > specified names. > This can be achieved in customized loader in current draft. > > var myLoader = new Loader(System, { > translate: function(src, relURL, baseURL, resolved) { > var frag = new URL(relURL).fragment // URL class parse the url > to uri components > if (frag == null) return src > var exportNames = src.split(/\s*,\s*/) > return wrap(src, exportNames) // wrap the src with AMD-style > function wrapper > } > }) > > But maybe System loader could support it directly. > > >> >> And, a library might have dependencies, and they might not be using >> ES6 modules to manage their dependencies, I might want the following >> thing: >> >> --------------------------------- >> import "jquery.min.js", "MyES5Module.js" as MyES5Module >> var dosth = MyES5Module.dosth; >> --------------------------------- >> >> Currently harmony:modules might not strong enough to cover these >> cases. My proposal is : >> >> 1. Export every thing by default. >> Since we have "import ... from ..." to protect our namespace there is >> no need to use “export”. If any author of library would like to hide >> local variable they will use anonymous function. >> >> 2.Allow multiple files in a module >> >> in Variant A: "import URL" syntax >> >> ------------------------------------ >> ModuleImport ::= StringLiteral "as" Id >> ------------------------------------ >> ===> >> ------------------------------------ >> ModuleImport ::= StringLiteral ("," StringLiteral)* "as" Id >> ------------------------------------ >> >> >> >> 2012/8/29 Kevin Smith <[email protected]>: >>> Four things: >>> >>> 1) The export grammar on the wiki allows: >>> >>> export *; >>> >>> Which I take to mean "export every local binding". What's the >>> justification? I don't think I've ever seen a ES5 "module" that didn't have >>> some local, non-exported state or function. >>> >>> 2) The grammar also allows: >>> >>> export * from Path.To.Module; >>> >>> which is fine. But I think it would also be convenient to provide the >>> following: >>> >>> export * from "SomeModule.js"; >>> >>> In particular, this form would be useful in "package main" files, where you >>> are combining the interface of several sub-modules into a single package >>> interface. Using only the allowed forms, we would need something like: >>> >>> import "SomeModule.js" as SomeModule; >>> export * from SomeModule; >>> >>> 3) I really like the module syntax (except for import *), and I would like >>> to see convergence on the syntax for importing to a module instance: >>> >>> import "SomeModule.js" as SomeModule; // or >>> module SomeModule = "SomeModule.js"; >>> >>> I personally like the former, but has there been any agreement on either >>> one? Until there's a decision, we can't proceed with bleeding-edge >>> transcompilation. : ) >>> >>> 4) Just a comment: the main argument in favor of "import *" is >>> convenience. But it's nearly as convenient to import to a module instance: >>> >>> import "A.js" as A; >>> A.x(); >>> A.y(); >>> >>> This is indeed what Node.js programmers are used to and I don't believe >>> there has been any gnashing of teeth over it. In my opinion, being able to >>> statically analyze a module in isolation outweighs the additional >>> convenience of import *. >>> >>> Thanks for your time! >>> >>> Kevin >>> >>> >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
