> > > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
