> > > To me, though, that goes back to the destructuring/not destructuring > aspect. Maybe this has floated by during the bikeshedding, but why not > something like: > > //import a single named export > import foo from "bar"; > > //import multiple named exports > import foo, baz from "bar"; > > //alias an imported named export > import foo as fooAlias from "bar"; > > //import the module > import "bar" as bar; > > : )
https://mail.mozilla.org/pipermail/es-discuss/2013-April/029841.html I tried this out in a parser and in real code, and was only moderately happy with the result. I find that I prefer the curlies. Bikeshedding aside, I think we pretty much agree across the board that the current setup which attaches special importance to a "default" export is confusing and suboptimal. It is clear to me that it does not satisfy the constituents that it is meant to satisfy. I agree with Russell that the only way to make "default" work is to have override semantics. That is, the user must be allowed to "override" the module instance object somehow. Since that approach is inherently "hacky", I doubt it will get consensus in TC39. With those two facts in mind, I think we need to see evidence that the "default" feature provides *more than marginal gains* in terms of user experience. If such evidence cannot be produced, then the "default" feature does not carry its weight and must be removed. So.... what's the evidence?
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
