ModuleImport

Kevin Smith zenparsing at gmail.com
Thu Jun 26 20:42:02 PDT 2014


>
>
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/4bd30988/attachment.html>


More information about the es-discuss mailing list