On Thu, Jun 19, 2014 at 6:57 AM, Erik Arvidsson <[email protected]> wrote:
> > 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. > > I think you're example misses one point - The module author changed the exported api, going from exporting a function named C to exporting an object with a property named C. Problems caused by this refactoring would exist regardless of Calvin's suggestion. Calvin's suggestion would allow the following refactoring to be done by the module author without impacting his users, something not possible with current ES6: ```js // a.js V1 export default { C: class C { ... } } // a.js V2 export class C { ... } ``` The refactoring hazard is real, but exists iff the module consumer uses implicit exports (i.e. an Object.prototype method with the above default export). This is another reason why the named export form is better - everything is explicit. IMO the only good reason to use default export is to export a single function. -chris
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
