On Thu, Jun 26, 2014 at 8:15 AM, Kevin Smith <zenpars...@gmail.com> wrote:
>
> I agree, and importing as a namespace is what ModuleImport is all about.
> Crazy idea: what if we had this:
>
> // ModuleImport: import Identifier from StringLiteral
> import fs from "fs";
> import url from "url";
>
> And just got rid of the default monkey-business? Simple, no confusion, no
> refactoring hazards.
>
> Do we *really* need assignable default exports? If we could jettison that
> feature, it would (as John points out) make all of this pain go away.
>
That would simplify the usage of modules (users wouldn't need to look up
which of the two ways the module author (arbitrarily) decided to use) and
it would simplify authoring of modules (only one way to export things). The
only real complaint we are likely to hear is that it would not allow single
export modules, which is the favoured usage of modules. I disagree with
this; a module that only exports one named thing is a single export module.
If you want to author a single export module then you only export one
thing, and users of your module only import one thing:
```js
//file AbstractSingletonProxyFactoryBean.js
export class AbstractSingletonProxyFactoryBean {
//...
}
//file MyApp.js
import {AbstractSingletonProxyFactoryBean} from
"AbstractSingletonProxyFactoryBean";
```
Now the author can choose to export more things later without making
breaking changes to the module. The only downside to this is the
(apparently mandatory) curly braces around the imported object. If single
export/import becomes the convention with ES6 modules then users will be
forced to type an extra pair of {} several times in most of their files. Is
the two extra characters something we can live with?
Marius Gundersen
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
