It's not just about interoperability. It's also about enabling the pattern
that proved itself to work quite well - module as a function, module as a
class, module as a function with named exports attached in one "namespace".
I suppose if that pattern is not explicitly supported it might be just fine
since perhaps we'll discover better patterns. And if not, we'll be able to
just always use 1 named export and do
```
import {fs} from "fs";
import {moment} from "moment";
import {$} from "jquery";
// etc.
```
In fact, doesn't being able to import things like above make es6 modules
already interoperable with CJS?
On Mon, Jun 30, 2014 at 8:00 PM, Kevin Smith <zenpars...@gmail.com> wrote:
>
>> What's not clear is the advantage of module bindings form for modules.
>> When the world of possibilities opens up, what specific things will I see
>> there?
>>
>
> I think I'm following you now. So let's pose the question like this:
>
> Let's posit that there are no default export or import forms, otherwise
> the current *syntax* is the same. Now, we have two semantic options that
> we can attach to that syntax:
>
> 1. Modules are just regular objects with getters. The import
> declarations just get properties from those objects at runtime.
> 2. Modules are a collection of named bindings. Those bindings are
> resolved at compile-time.
>
> Now, since the syntax is the same, our ability to do offline static
> analysis is the same. So what are the differences between these two
> semantics?
>
> (All of this has been gone over before, of course...)
>
> Advantages of 1:
>
> - None?
>
> Advantages of 2:
>
> - Good support for circular dependencies
> - Mutable bindings
> - Compile-time optimizations for "module.member" expressions
>
> The advantage of 1 only appears if we allow module object overwriting.
> Those advantages are:
>
> - Auto-renaming the import (questionable)
> - Smoother interoperability with CommonJS modules.
>
> On the other hand, module object overwriting disables our ability to do
> offline static analysis.
>
> So I think the only forceful argument if favor of option 1 (i.e. modules
> are regular objects with getters) is interoperability, and only if we allow
> export overwriting.
>
> The interoperability question is therefore of central importance.
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
