I've used es6 modules for several months now and I'm curious to know when I
would want to leverage mutable bindings.

I guess I need to begin to imagine that variables bound to imports are
really a kind of property name of s secret object:

import { foo, changeFoo } from "./module1";

console.log(foo); // Oh, yeah, this really means module1.foo
changeFoo();
console.log(foo); // Ok, since this is secretly module1.foo, the result
'10' makes sense.

jjb

On Fri, Mar 14, 2014 at 7:40 AM, Domenic Denicola <
domenic at domenicdenicola.com> wrote:

>
> ```js
>
> // module1.js
> export let foo = 5;
> export function changeFoo() {
>     foo = 10;
> }
>
> // module2.js
> import { foo, changeFoo } from "./module1";
>
> // Import imports mutable bindings
> // So calling changeFoo will change the foo in current scope (and original
> scope)
>
> console.log(foo); // 5
> changeFoo();
> console.log(foo); // 10
>
> // module3.js
> module module1 from "./module1";
> let { foo, changeFoo } = module1;
>
> // Destructuring uses assignment to copy over the current values
> // So calling changeFoo does not affect this binding for foo
>
> console.log(foo); // 5
> changeFoo();
> console.log(foo); // 5
>
>
>
>
>
> From: John Barton <johnjbarton at google.com>
> Sent: Friday, March 14, 2014 10:35
> To: Domenic Denicola
> Cc: Mark Volkmann; Kevin Smith; es-discuss at mozilla.org
> Subject: Re: module exports
>
>
> What is a 'mutable binding'?
>
>
>
> On Fri, Mar 14, 2014 at 7:30 AM, Domenic Denicola  <
> domenic at domenicdenicola.com> wrote:
>
>
> Importing is nothing like destructuring. You import mutable bindings; you
> don't do assignment. I'm very glad that different syntax is used for each
> case.
>
>
>
> From: Mark Volkmann <r.mark.volkmann at gmail.com>
> Sent: Friday, March 14, 2014 10:19
> To: Kevin Smith
> Cc: Domenic Denicola;  es-discuss at mozilla.org
> Subject: Re: module exports
>
>
>
>
> I understand it's hard to make changes after a certain point. It's too bad
> though that developers will have to remember that the way to import a few
> things from a module is:
>
>
> import {foo, bar} from 'somewhere';
>
>
> but the way to import the whole module is:
>
>
> module SomeModule from 'somewhere';
>
>
> instead of
>
>
> import SomeModule from 'somewhere';
>
>
> It just seems so clean to say that if you want to import something, you
> always use the "import" keyword.
>
>
>
> On Fri, Mar 14, 2014 at 9:12 AM, Kevin Smith  <zenparsing at gmail.com>
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>     export { foo as default };
>
>
>
> I fail to see why sugar over this form is necessary.
>
>  I completely agree. Plus if this is taken away then the "import" keyword
> can be used to get the whole module as in my example above. At that point
> maybe there is no need for the "module" keyword.
>
>
> Maybe, but at this point that would be too big of a change to swallow.  I
> think if we can just focus on eliminating this one pointless and confusing
> aspect (the export default [expr] form), we'll be good to go.
>
>
>
>
>
>
>
>  --
> R. Mark Volkmann
> Object Computing, Inc.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140314/530eef5d/attachment.html>

I've used es6 modules for several months now and I'm curious to know when I
would want to leverage mutable bindings.

I guess I need to begin to imagine that variables bound to imports are
really a kind of property name of s secret object:

```js
import { foo, changeFoo } from "./module1";

console.log(foo); // Oh, yeah, this really means module1.foo
changeFoo();
console.log(foo); // Ok, since this is secretly module1.foo, the result '10' makes sense.
```