export questions

程劭非 csf178 at gmail.com
Fri Aug 31 00:16:19 PDT 2012


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.$;
---------------------------------

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
>


More information about the es-discuss mailing list