Rationale for dropping ModuleImport syntax?

[Marius Gundersen]

On Tue, Jun 10, 2014 at 1:13 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> ```
>> ImportClause :
>>   ImportedBinding
>>   ImportedBinding , NamedImports
>>   NamedImports
>> ```
>>
>>
> Side topic, but this particular production:
>
>      ImportClause: ImportedBinding , NamedImports
>
> needs to die an immediate death.
>

Yeah, ModuleImport isn't the only thing that needs to be removed from the
spec.


>
>>  Or would the default value be an object containing all the named export
>> values?
>>
>
> No - the default has no default, as it were.
>

So if the module does not define a default export, then it must be imported
using the `import {foo} from "foo"` syntax, and not the `import bar from
"bar";` syntax. And if it only has a default export, then it must be
imported using the second statement (`import bar from "bar"`) and not the
first (`import {foo} from "foo"`). Without looking at the source of the
module you wish to import you cannot know which of these two import
statements to use.

But, IIUC, the spec lets you export both a default value and named values.
Most libraries will have to use both of these exports, so users can choose
which import statement to use. So for underscore.js:

```js
var _ = { /*....*/ };

export default = _;
export {_.map as map, _.reduce as reduce, _.filter as filter, /*...*/};
```

But there is nothing to ensure that the two exports are the same object
(which for underscore will likely lead to bugs):

```js
export default = 5;
export {1 as a};

//in another module
import {a} from "sillyModule";//a is 1
import a from "sillyModule"; //a is 5
```

This will likely lead to a lot of confusion, not only for module makers but
also for module consumers.

Marius Gundersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140610/bc2092bf/attachment.html>