ModuleImport

[Calvin Metcalf]

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>