export questions

Shijun He hax.sfo at gmail.com
Fri Aug 31 01:13:52 PDT 2012


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