On Thu, Jun 19, 2014 at 1:15 AM, David Herman <dherman at mozilla.com> wrote:
> ## Proposal
>
> OK, so we're talking about a better syntax for importing a module and binding its named exports to a variable (as distinct from importing a module and binding its default export to a variable). Here's my proposal:
> ```js
> import * as fs from "fs"; // importing the named exports as an object
> import Dict from "dict";  // importing a default export, same as ever
> ```

Two other possibilities:

1) Only allow export default or named exports, not both.

The reason default export is used in module systems today is because
there is just one thing that wants to be exported, and it does not
matter what its name is because it is indicated by the module ID.
Sometimes it is also easier to just use an object literal syntax for
the export than expanding that out into individual export statements.

Allowing both default and named exports from the same module is
providing this syntax/API extension. If there are ancillary
capabilities available, a submodule in a package is more likely the
way it will be used, accessed as a default export via a module ID like
‘mainModule/sub', instead of wanting to use a default and named export
from the same module.

It would look like this:

import fs from ‘fs’; // only has named exports, so get object holding
all the exports
import { readFile } from ‘fs’; // only the readFile export
import Dict from ‘dict’; // a default export

— or —

2) Only allow `export` of one thing from a module, and `import {}`
just means allowing getting the first property on that export. This
removes the named export checking, but that benefit was always a bit
weak, even weaker with the favoring of default export.

//d.js, module with a default export, note it does not need a name,
//`export` can only appear once in a file.
export function() {};

//fs.js, module with “multiple” us
export {
  readFile: function(){}
};

//main.js using ‘d’ and ‘fs'
import d from ‘d’;
import { readFile } from ‘fs’;

—

Both of those possibilities also fix the disjointed Sytem.import() use
with a default export. No need to know that a `.default` is needed to
get the usable part. It will match the `import Name from ‘id’` syntax
better.

James

> On Thu, Jun 19, 2014 at 1:15 AM, David Herman <dherman at mozilla.com> wrote:
> ## Proposal
>
> OK, so we're talking about a better syntax for importing a module and binding its named exports to a variable (as distinct from importing a module and binding its default export to a variable). Here's my proposal:
> ```js
> import * as fs from "fs"; // importing the named exports as an object
> import Dict from "dict";  // importing a default export, same as ever
> ```

Two other possibilities:

1) Only allow export default or named exports, not both.

The reason default export is used in module systems today is because
there is just one thing that wants to be exported, and it does not
matter what its name is because it is indicated by the module ID.
Sometimes it is also easier to just use an object literal syntax for
the export than expanding that out into individual export statements.

Allowing both default and named exports from the same module is
providing this syntax/API extension. If there are ancillary
capabilities available, a submodule in a package is more likely the
way it will be used, accessed as a default export via a module ID like
‘mainModule/sub', instead of wanting to use a default and named export
from the same module.

It would look like this:
```js
import fs from ‘fs’; // only has named exports, so get object holding
all the exports
import { readFile } from ‘fs’; // only the readFile export
import Dict from ‘dict’; // a default export
```
— or —

2) Only allow `export` of one thing from a module, and `import {}`
just means allowing getting the first property on that export. This
removes the named export checking, but that benefit was always a bit
weak, even weaker with the favoring of default export.
```js
//d.js, module with a default export, note it does not need a name,
//"export" can only appear once in a file.
export function() {};

//fs.js, module with “multiple” us
export {
  readFile: function(){}
};

//main.js using ‘d’ and ‘fs'
import d from ‘d’;
import { readFile } from ‘fs’;
```
—

Both of those possibilities also fix the disjointed `Sytem.import()` use
with a default export. No need to know that a `.default` is needed to
get the usable part. It will match the `import Name from ‘id’` syntax
better.

James