On Fri, Mar 14, 2014 at 11:42 AM, David Herman <dher...@mozilla.com> wrote:
>
>
> 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.
Ok great, so one solution to potential confusion caused by 'import' is
simply to always use 'module'.
> 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.)
>
If I am understanding correctly, I'm skeptical because the semantics of
these bindings resemble the semantics of global variables. Our experience
with global variables is that they make somethings easy at the cost of
creating opportunities for bugs. Function arguments and return values
provide a degree of isolation between parts of programs. Bindings allow two
parts of a program, related only by importing the same module, to interact
in ways that two functions called by the same function could not. The
coupling is rather like public object properties but without the object
prefix to remind you that you are interacting with shared state. That's
where the 'module' form may be more suitable: I expect 'm.bar' to have a
value which might change within my scope due to operations in other
functions.
>
> Dave
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
