On Mon, Jun 30, 2014 at 12: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? > Thanks! This is the kind of information I was hoping for. > > (All of this has been gone over before, of course...) > Perhaps, but clear explanation of complex topics is difficult. Isolating the issues and getting to specifics helps. In that spirit I'll ask for more details. > > Advantages of 1: > > - None? > > Advantages of 2: > > - Good support for circular dependencies > - Mutable bindings > As far as I know, this is not something JS developers understand. What is it and what makes it an advantage? > - Compile-time optimizations for "module.member" expressions > Is this known to be significant and fundamental? As in there is no way to achieve this optimization with the other format? Seems to me that the compiler introduces the getters and thus can inline them. > The advantage of 1 only appears if we allow module object overwriting. > Concretely you mean monkey patching module objects in the importing code? Or? > 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. > Based on other discussion on this point, it seems like module-as-named-bindings can interoperate with CJS and AMD except perhaps in some unusual cases. Clarifying these cases would help. To me, these two lists are pretty darn small compared with the overall advantages of modules. jjb
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
