`import` and aliasing bindings

Kevin Smith khs4473 at gmail.com
Fri Dec 28 08:25:49 PST 2012

module "foo" {
>  export let state = 5;
>  export function modifyState() {
>    state = 10;
>  };
> }
> import { state, modifyState } from "foo";
> assert(state === 5);
> modifyState();
> assert(state === 10);

That's it.

> This is, to me as an ES5 programmer, very weird. There is *no other
> situation in the language* where what an identifier refers to can change
> without me assigning to it.

Chicken and egg.  It's doesn't exit because ES doesn't have modules.  Node
"modules" are just functions, remember.

 This is compounded by the syntax used by `import`. The
> pseudo-destructuring microsyntax, plus the superficially declaration-like
> nature of that line, make you expect it to behave like a normal `let` or
> `var` declaration with destructuring assignment, which we are used to from
> CoffeeScript, Python, JS 1.8, etc. Obviously, it's a very different animal.

Yes - and I agree that false symmetry should be avoided.  On the other
hand, it would be awkward to have the import renaming syntax completely
out-of-line with destructuring syntax.

Finally, I can't shake the feeling I'm missing something. Why is this
> aliasing property valuable, given that it's so contradictory to
> expectations? I am totally on board with the need for static analysis and
> thus top-level-only import and export statements. The "just copy Node"
> peanut gallery is wrong, and the static analysis is not only necessary for
> asynchronous browser loading, but also adds a lot of power to the language.
> But what does the aliasing add? Is it connected to static analysis in some
> way I don't understand?

Well, it also allows proper circular dependencies, for one.

{ Kevin }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121228/537b68a2/attachment.html>

More information about the es-discuss mailing list