On Thu, Jun 19, 2014 at 6:41 AM, Calvin Metcalf <[email protected]>
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" <[email protected]> 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
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
erik
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
