<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg <span dir="ltr"><<a href="mailto:rossberg@google.com" target="_blank">rossberg@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  - It removes the syntactic marker for binding a module identifier.<br>
That is problematic because (a) module identifiers come with extra<br>
static checks on their uses (or so I thought, see below), and it is<br>
(b) future hostile to lexical module declarations, because with those,<br>
only module identifiers could be used in certain contexts (e.g., on<br>
the RHS of an import-from). Thinking forward, I think it would be<br>
highly preferable to consistently mark all bindings of module<br>
identifiers with a 'module' keyword.<br></blockquote><div><br></div><div>I disagree here.  I think certain people are too hung up on what is a "real module" and what is an "object pretending to be a module".  For lots of legacy code (think jquery), we have objects like `$` which are actually both functions *and* modules (in the form of namespaces).  The JS community can handle this.  Honestly, most of the fun features of "real modules" are obscure corner cases anyway (like lazy binding).  We can deal with a few oddball "modules" which are not actually module objects.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  - Some want modules in the conventional sense, as encapsulated<br>
namespaces with named exports, which you can import and access<br>
qualified or unqualified, and where imports are checked.<br>
<br>
  - Some want modules in the specific pre-ES6 JavaScript style, where<br>
they can be any arbitrary JS value, and in the good old JavaScript<br>
tradition that checking doesn't matter.<br>
<br>
The current design (including the newest suggestions for imports)<br>
seems to please neither side, because it tries to be the former<br>
semantically, but wants to optimise for the latter syntactically. The<br>
main outcome is confusion.<br></blockquote><div><br></div><div>I think the problem is somewhat different, in that certain people resist the idea that some "modules" might not be actual modules.  I think we could embrace that and the result would be *less* confusion (since we wouldn't require a syntactic marker for "real module").  It will be rare for someone to notice that `$.foo` is not lazily-bound, or that `$.module.path` (or whatever) isn't actually defined.  If they care, they can file a bug against jquery.  jquery should be able to either emulate the module functionality (duck typing!  but this is one of the things that annoys me about the current way lazy binding works) or decide that backwards-compatibility or whatever is more important and ignore the issue.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  - Either we think "real" modules are an improvement, and checking is<br>
important. Then the model and the syntax should be consistent about<br>
that. Moreover, checking needs to consistently apply, no matter how a<br>
module and its components are defined or accessed.<br>
<br>
  - Or we come to the conclusion that supporting the legacy singleton<br>
export model as a primary use case is a mandatory matter. Then we<br>
should drop attempts of building something in/semi-compatible, and<br>
limit innovation to making export and import declarative, and<br>
designing a loader API.<br></blockquote><div><br></div><div>Again, I think it's the "either/or" mindset which is the problem here.  We can actually have both.  Sometimes we won't be able to do strict checking.  Sometimes we will.  We don't need to force everyone into the same mold.  Let the author of the module decide how important static checking, lazy binding, ease-of-use, etc, is and define their module appropriately.  (And the same for the "importer of the module".)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Quite honestly, I rather have no import checking than checking that<br>
only applies in some syntactic cases -- because that gives a false<br>
sense of security, harms refactoring, and/or encourages overuse of<br>
unqualified imports, hampering readability.</blockquote><div><br></div><div>Again: is this what's hampering compromise?  Can't we let the module author (and/or importer) decide the extent to which they think checking is important?</div>
<div><br></div><div>Yes, modules will be a compromise design.  But it's a compromise design because of *network effects* and *programmer preference*.  There are large and useful codebases organized around different principles.  We can't force them all into the same mold.  Programming is still an art form and a matter of taste; let's go easy on the mandates.</div>
<div>  --scott (who actually thinks that current modules spec is not that bad, although it could be slightly improved)</div></div></div></div>