export questions

[Shijun He]

On Fri, Aug 31, 2012 at 6:24 PM, 程劭非 <csf178 at gmail.com> wrote:
> What does it look like if you want to import more than one variables
> from one module?

import {a,b} from "oldscript.js#a,b"

>
> 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