Module Comments

Nathan Wall nathan.wall at live.com
Sun Dec 9 08:00:24 PST 2012


Yeah, that makes sense. I agree. Thanks.

Nathan
> 
> 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
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121209/964fa5d0/attachment.html>


More information about the es-discuss mailing list