ModuleImport

Chris Toshok toshok at gmail.com
Thu Jun 19 10:04:50 PDT 2014


On Thu, Jun 19, 2014 at 7:13 AM, Calvin Metcalf <calvin.metcalf at gmail.com>
wrote:

> > With this idea you cannot look at the import statement to see if the
> imported binding is a module instance object or not.
>
> the flip side of that is that you don't need to know whether something is
> a default export or a named export to import it e.g.
>
>

and elsewhere James Burke wrote:



> 1) Only allow export default or named exports, not both.
>
>
I wrote about both of these issues here the other day:


https://blog.toshokelectric.com/too-little-too-late-my-thoughts-on-es6-modules/

IMO you can't really implement Calvin's suggestion without making
default+named exports an early error, since you don't know where the
bindings should come from if a module contains both.

This would be great from the perspective of decoupling import/export
syntaxes.  But mutable bindings gum up the works, in that they provide
another avenue for anti-refactoring pressure to flow from module consumer
to module author, and the proposed syntax changes here (not by David) as
well as in my post would make their behavior even more of a hazard.  The
syntaxes need to remain coupled in some form because you really *do* want
to know if you're getting a mutable binding or not.

David's `import * as foo from 'foo'` proposal gets us close enough to the
ideal of what's possible now, that it's definitely a +1 here.

ES6 favors the single/default export style, and gives the sweetest syntax
> to importing the default
>

Coupling in action :/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140619/b46dc9e3/attachment.html>


More information about the es-discuss mailing list