Now that I have fully digested Andreas's points from the earlier thread on
modules [1], I am a bit concerned about the implications of `import`
introducing aliasing bindings. To recap, the situation is:
module "foo" {
export let state = 5;
export function modifyState() {
state = 10;
};
}
import { state, modifyState } from "foo";
assert(state === 5);
modifyState();
assert(state === 10);
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. Properties of objects, sure. But not bare identifiers. (Well,
I guess `with` blurs this line. And the global object. No comment.)
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.
Notably, such aliasing is out of line with all current ES6 transpilers (Traceur
[2], Six [3], Yehuda's js_module_transpiler [4]; TypeScript doesn't allow
importing from modules, just importing module instance objects). Emulating such
semantics would necessitate a desugaring that imports the module instance
object, then rewrites all references to the imported identifiers to instead
refer to properties of the imported module instance object. This is much more
of a transformation than you'd expect, and of course falls down in the face of
e.g. `eval("sta" + "te")`. The very fact that such a rewriting to
object-property-access is necessary underscores how strange imported
identifiers really are. I think people are in for a rude surprise moving from
the transpiled world to the native ES6 world, and such semantics mean that a
hybrid future---e.g. transpile for IE<=10, native for IE>=11---is laden with
footguns waiting to be set off.
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?
[1]: https://mail.mozilla.org/pipermail/es-discuss/2012-December/027021.html
[2]: http://tinyurl.com/ctvo8wr
[3]: https://gist.github.com/4347076
[4]: https://github.com/wycats/js_module_transpiler#individual-imports
P.S. One solution, if aliasing is indeed super-valuable, would be to move away
from pseudo-destructuring microsyntax to one that's more alien, and thus
connotes that something "strange" (or at least "unlike destructuring") is going
to happen. Perhaps `import <state, modifyState> from "foo"`. This could be
symmetrized on the export side: `export` takes a weird `ExportSpecifierSet`
that looks something like an object literal, but behaves nothing like it, so
maybe `export <state, modifyState>` would make this weirdness clearer.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
