Module Comments

Kevin Smith khs4473 at gmail.com
Wed Dec 5 19:16:34 PST 2012


I've had a look at the changes to the modules wiki page [1].  I'm liking
the syntax changes quite a lot actually, but I have a couple of comments:

1) "export" ExportSpecifierSet ("," ExportSpecifierSet)* ";"

This rule seems too permissive.  It allows strange combinations like:

    export x, { y: a.b.c, z }, { j, k }, * from "bloop";

I think it would be better to flatten it out a little bit:

    ExportDeclaration: "export" "{" ExportSpecifier ("," ExportSpecifier)*
"}" ";"
    ExportDeclaration: "export" Identifier ("," Identifier)* ";"
    ExportDeclaration: "export" "*" "from" StringLiteral ";"

2) Do we need `export *;`?

I don't see the point of exporting every declaration in the current module
scope.  If the programmer wants to export a bunch of stuff, the other forms
make that sufficiently easy.  Exporting everything encourages bad
(de-modular) design.

3) I'm just OK with "as".  Note that it inverts the position of the string
and the binding:

    import { x } from "goo";
    import "ga" as ga;

Which makes it harder to read when you have a bunch of imports mixed
together.  It's harder for the eyes to scan back and forth.

4) Why was this form eliminated?

    import x from "goo";  // Note lack of curlies!

In an object-oriented application, we're often going to be importing a
single thing (the class) from external modules.  So we may see long lists
like this:

    import { ClassA } from "ClassA.js";
    import { ClassB } from "ClassB.js";
    ....
    import { ClassZ } from "ClassZ.js";

Removing the curlies for this simple case would seem like a win.

5) Dynamic exports via `export = ?` could make interop with existing module
systems easier.  But how does that work?

6) Adding ".js" as the default resolution strategy:

I don't think this is tenable.  First, there's the practical issue of what
happens when someone actually wants to load a resource without a ".js"
extension?

Second, there's the philosophical problem of essentially setting up an
alternate URL scheme.  That's fine for libraries like AMD loaders or YUI.
 But EcmaScript is a cornerstone of the internet.  External resource
resolution can't conflict with HTML/CSS/etc.

- Kevin

[1]  http://wiki.ecmascript.org/doku.php?id=harmony:modules
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121205/46d8da0f/attachment.html>


More information about the es-discuss mailing list