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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
