On Mar 14, 2014, at 9:27 AM, John Barton <johnjbar...@google.com> wrote:
> I've used es6 modules for several months now and I'm curious to know when I
> would want to leverage mutable bindings.
So cycles work!
// model.js
import View from "view";
export default class Model {
...
}
// view.js
import Model from "model";
export default class View {
...
}
This kind of thing just falls flat on its face in Node and AMD.
> I guess I need to begin to imagine that variables bound to imports are really
> a kind of property name of s secret object:
If that gets you there, that's cool. But it's a bit sloppy. It blurs userland
data structures with internal language implementation data structures.
Here's how I think about it. A variable in JS denotes a "binding", which is
basically an association with a mutable location in memory. In particular it
doesn't denote a value. The binding has a value at any given time.
When you export from a module, you're exporting bindings, rather than values.
This means you can refactor between
module m from "foo";
...
m.bar
and
import { bar } from "foo";
...
bar
and they're fully equivalent. But it also means that when you have modules that
mutate their exports during initialization, you don't run into as many subtle
order-of-initialization issues as you do with AMD and Node, because importing
something syntactically early doesn't mean you accidentally snapshot its
pre-initialized state.
(Also, keep in mind that the vast majority of module exports are set once and
never changed, in which case this semantics *only* fixes bugs.)
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
