Hi Kevin,

Thanks, I do agree with most of your points, but it doesn't take into account 
anonymous export. I'm gonna bite the bullet here and tempt the bikeshedding 
demons by making an incremental suggestion for a syntax for anonymous 
import/export that adds to your syntax.

    export default f(1, 2, 3);        // creates anonymous export by evaluating 
RHS expression

    import default as foo from "foo"; // binds the anonymous export from module 
"foo" to variable foo

The downside of this is that it's a little chatty for what we expect to be the 
common case of modules with just a single export or modules where the vasty 
majority of the time you want the default export. But it has a nice symmetry 
and builds on your (valid) points.

Dave

On Apr 16, 2013, at 6:06 AM, Kevin Smith <[email protected]> wrote:

> Currently, curly braces are used within import and export declarations:
> 
>     import { something } from "url";
>     import { something: renamed } from "url";
>     import { a, b, c } from "url";
> 
>     export { something };
>     export { renamed: something };
>     export { a, b, c };
> 
> The import and export curlies are analogies for destructing and object 
> literal syntax, respectively.  This analogy is problematic for the following 
> reasons:
> 
> 1) Destructuring declarations create new variables, whereas import 
> declarations create aliases for existing variables.  This distinction is 
> subtle and can lead to misunderstandings about module semantics.
> 
> 2) Beginners tend to get the "direction" of renaming wrong with destructuring 
> syntax:
> 
>     let { myX: x } = { x: "value" }; // Oops!
> 
> Since destructuring is an intermediate to advanced feature, it's not a big 
> problem in that context.  But importing is one of the most basic features in 
> the language.  We don't want to have a stumbling block right at the front 
> door.
> 
> 3) Curly braces within export declarations suggest a false semantics in which 
> an object literal expression can be exported:
> 
>     // Since is ok:
>     export { exportedA: a };
> 
>     // It leads one to believe that this is ok:
>     export { exportedA: "some-value" };
> 
> Given those considerations, I think we should find a curly-free syntax for 
> import and export declarations.  Here is a proposal:
> 
>     import something from "url";
>     import something as renamed from "url";
>     import a, b, c from "url";
> 
>     export something;
>     export something as renamed;
>     export a, b, c;
> 
> In the above syntax, "as" becomes the unified keyword for renaming module 
> bindings.
> 
> For an analysis of the ASI issues, see: 
> https://gist.github.com/zenparsing/5395635
> 
> { Kevin }
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to