module exports

[C. Scott Ananian]

On Fri, Mar 14, 2014 at 3:34 PM, John Barton <johnjbarton at google.com> wrote:
> On Fri, Mar 14, 2014 at 11:42 AM, David Herman <dherman at 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'.

Another way to put this is that changing:
```js
import { bar } from "foo";
```
to
```js
module m from "foo";
let bar = m.bar;
```
will always be a subtle source of bugs.

Looked at another way, the module spec is introducing a new sort of
assignment statement, where the bindings are mutable.  But instead of
adding this as a high-level feature of the language, it's being
treated as a weird special case for modules only.

I would be happier introducing a general purpose "mutable binding
assignment" like:
```js
let mutable bar = m.bar;
```
where every reference to bar is always treated as a dereference of
`m.bar`.  That way the new assignment feature isn't pigeonholed as a
weird part of the module spec.

Couldn't we assemble the desired semantics out of pre-existing
primitives, instead of inventing new stuff?  For example, if `m.bar`
in the example above was a proxy object we could preserve the desired
"mutable binding" without inventing new language features.
 --scott

ps. I foresee a future where modules are (ab)used to create mutable
bindings.  Better to make them first-class language features!

pps. Circular references work just fine in node.  You have to be a
little careful about them, but the 'mutable bindings' don't change
that.  They just introduce `bar` as a new shorthand for writing
`m.bar`.  IMHO the latter is actually preferable, as it makes it
obvious to the author and reader of the code exactly what is going on.