ModuleImport

Karolis Narkevičius karolis.n at gmail.com
Mon Jun 30 12:59:25 PDT 2014


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 <zenparsing at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/9c491429/attachment.html>


More information about the es-discuss mailing list