ModuleImport

Kevin Smith zenparsing at gmail.com
Mon Jun 30 12:00:10 PDT 2014


>
>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140630/398606bc/attachment.html>


More information about the es-discuss mailing list