Yeah, that makes sense. I agree. Thanks.
Nathan
>
> 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
