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 <[email protected]> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
--
-Calvin W. Metcalf
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
