ModuleImport
Calvin Metcalf
calvin.metcalf at gmail.com
Tue Jul 1 10:36:16 PDT 2014
one benefit of default exports is forcing people to choose one of
export { x as exports };
export { x as default };
export { x as _ };
this is the one chance to get everyone on the same page
as far as object-as-module having circular dependency issues, can you
elaborate on that, I understand how
let {foo, bar} = import './baz';
would have circular reference problems (amongst other issues), but
module name from './path'
...
name.method();
is (~)what node uses and has comparable (better for certain things, worse
for others) circular dependency support (source: writing a CJS loader using
the es6 loader hooks api) the difficulties I can see with modules as
objects involve static analysis.
On Tue, Jul 1, 2014 at 1:22 PM, Kevin Smith <zenparsing at gmail.com> wrote:
>
> If it had good enough support for circular dependencies, would we be able
>> to make sense of "module-as-module" designs?
>>
>
> Side note: I meant "object-as-module" really. It's kinda funny that I
> capped off all of that with such a silly mistype. : )
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
-Calvin W. Metcalf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140701/60c1d5bf/attachment.html>
More information about the es-discuss
mailing list