On 28 December 2012 16:20, Domenic Denicola <domenic at domenicdenicola.com>wrote:

>  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.)
>
> [...]
> 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?
>

Your expectations must be different than mine. :)

Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other things) a
name spacing mechanism. That implies two axioms:

1) You should always be able to access an export under its qualified or
unqualified name, with the same meaning. That is,

  M.a = 5;

and

  import a from M;
  a = 5;

should have the same meaning.

2) You should always be able to wrap existing code into a module without
changing its meaning. That is, given

  let a = 4;
  // ...
  a = 5;

it should be possible to refactor 'a' (plus other declarations) into a
module without changing the meaning of use sites, like:

  module M {
    export let a = 4;
    // ...
  }
  // ...
  import a from M;
  a = 5;

I think that the loss of either of these properties would make modules far
more surprising, and refactoring code into modules harder and more
error-prone.

I wouldn't worry too much about current source-to-source compilers for ES6
not getting this right yet. That is mainly due to the lack of a detailed
specification. I could enumerate quite a few other fundamental things that
they don't have right yet (e.g. recursive linking, static checking, etc.).

However, I agree that the destructuring syntax for module imports may not
be the clearest choice in terms of raising the right expectations. (As we
have discovered already, it has other issues, namely people confusing the
direction of renaming.) Maybe it is a bit too clever, and considering
alternatives a worthwhile idea.

/Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121228/52b571d7/attachment-0001.html>

Your expectations must be different than mine. :)

Dave and Sam may have a different answer, but I'd answer that the aliasing
semantics follows from a module system's role as (among other things) a
name spacing mechanism. That implies two axioms:

1. You should always be able to access an export under its qualified or unqualified name, with the same meaning. That is,

   ```js
   M.a = 5;
   ```

   and

   ```js
   import a from M;
   a = 5;
   ```

   should have the same meaning.

2. You should always be able to wrap existing code into a module without changing its meaning. That is, given

   ```js
   let a = 4;
   // ...
   a = 5;
   ```

   it should be possible to refactor 'a' (plus other declarations) into a module without changing the meaning of use sites, like:

   ```js
   module M {
     export let a = 4;
     // ...
   }
   // ...
   import a from M;
   a = 5;
   ```

I think that the loss of either of these properties would make modules far
more surprising, and refactoring code into modules harder and more
error-prone.

I wouldn't worry too much about current source-to-source compilers for ES6
not getting this right yet. That is mainly due to the lack of a detailed
specification. I could enumerate quite a few other fundamental things that
they don't have right yet (e.g. recursive linking, static checking, etc.).

However, I agree that the destructuring syntax for module imports may not
be the clearest choice in terms of raising the right expectations. (As we
have discovered already, it has other issues, namely people confusing the
direction of renaming.) Maybe it is a bit too clever, and considering
alternatives a worthwhile idea.