Module Comments

Andreas Rossberg rossberg at google.com
Sun Dec 9 07:17:39 PST 2012


On 9 December 2012 15:04, Nathan Wall <nathan.wall at live.com> wrote:
>> The problem is that imports are not normal variable assignments. They
>> do not copy values, like normal destructuring, they are aliasing
>> bindings! If you were to allow arbitrary expressions and patterns,
>> then this would imply aliasing of arbitrary object properties. Not
>> only is this a completely new feature, it also is rather questionable
>> -- the aliased location might disappear, because objects are mutable.
>
> Could it be structured so that using `export` directly on a variable
> exported the alias, while using `import { x: [ a, b ] } from A; ` was
> basically just sugar for `import { x } from A; let [ a, b ] = x;` so that a
> and b copied not aliased?

That's what I referred to when I wrote:

> You could arguably make this saner by interpreting nested patterns in
> an import as copying, not aliasing, but I think mixing meanings like
> that would be rather confusing and surprising.

So yes, you could do that, but no, I don't think it is a good idea.
Your example:

>     import { x: { a, b }, f } from A;
>     f();
>     print(a); // 1
>     print(b); // 2
>
>     ...
>
>     import { x, f } from A;
>     f();
>     print(x.a); // 3
>     print(x.b); // 4

demonstrates perfectly how it violates the principle of least surprise
and can potentially lead to subtle bugs, especially when refactoring.
One overarching principle of destructuring should be that all
variables in one binding are treated consistently.

/Andreas


More information about the es-discuss mailing list