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

> One other option could be for import name from 'path'  to resolve to the
> module body there is no default export, thanks to the static analysis
> you'll always know when default is present.
>
That is a refactoring hazard. If the module changes to add/remove the
default export the import will still succeed but the value is either a
module instance object or anything:

// a.js
export default class C { ... }

// importer.js
import A from './a';
new A();

Now a.js changes.

// a.js V2
export class C { ... }

// importer.js
import A from './a';
new A();  // TypeError: A is not a function

With this idea you cannot look at the import statement to see if the
imported binding is a module instance object or not.



>  The import 'path'/this.get syntax is a lot less burdensome if it's only
> required by edge cases like needing both default export and all the named
> ones.
> On Jun 19, 2014 6:32 AM, "Michał Gołębiowski" <m.goleb at gmail.com> wrote:
>
>> Thanks, Dave, for bringing that up, it shows you're open for feedback.
>> That said (bikeshed begins), what's wrong with:
>> ```js
>> import "fs" as fs;
>> ```
>> ? I feel that a lot of effort went in ES6 into reducing boilerplate via
>> e.g. arrow functions, classes etc. but if you start with Node's require,
>> this adds clutter. Compare these 3 forms of importing all the module
>> "lodash" bindings to an object _:
>> ```js
>> var _ = require("lodash"); // Node
>> import * as _ from "lodash"; // Dave's syntax
>> import "lodash" as _;
>> ```
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
erik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140619/ddf70d39/attachment-0001.html>

> On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <calvin.metcalf at gmail.com> wrote:
>
> One other option could be for import name from 'path'  to resolve to the
> module body there is no default export, thanks to the static analysis
> you'll always know when default is present.

That is a refactoring hazard. If the module changes to add/remove the
default export the import will still succeed but the value is either a
module instance object or anything:

```js
// a.js
export default class C { ... }

// importer.js
import A from './a';
new A();
```

Now a.js changes.
```js
// a.js V2
export class C { ... }

// importer.js
import A from './a';
new A();  // TypeError: A is not a function
```

With this idea you cannot look at the import statement to see if the
imported binding is a module instance object or not.