On 9 December 2012 15:04, Nathan Wall <nathan.w...@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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
