export questions

程劭非 csf178 at gmail.com
Fri Aug 31 03:24:43 PDT 2012


What does it look like if you want to import more than one variables
from one module?

2012/8/31 Shijun He <hax.sfo at gmail.com>:
> On Fri, Aug 31, 2012 at 3:16 PM, 程劭非 <csf178 at gmail.com> 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 <khs4473 at gmail.com>:
>>> 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
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list