On 27 June 2014 18:36, C. Scott Ananian <ecmascr...@cscott.net> wrote: > On Fri, Jun 27, 2014 at 9:07 AM, Andreas Rossberg <rossb...@google.com> > wrote: >> >> - It removes the syntactic marker for binding a module identifier. >> That is problematic because (a) module identifiers come with extra >> static checks on their uses (or so I thought, see below), and it is >> (b) future hostile to lexical module declarations, because with those, >> only module identifiers could be used in certain contexts (e.g., on >> the RHS of an import-from). Thinking forward, I think it would be >> highly preferable to consistently mark all bindings of module >> identifiers with a 'module' keyword. > > 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.
I think you are missing the central problem. If imports/exports are to be statically checked, then module bindings, their exports, and their uses have to be statically recognisable and analysable. That prohibits intermixing "proper" modules with other random objects. Furthermore, it also requires module identifiers to be distinguishable by context. (And my point above was that, since this matters for the semantics, the programmer is best served when she can immediately distinguish binding forms accordingly.) >> - Some want modules in the conventional sense, as encapsulated >> namespaces with named exports, which you can import and access >> qualified or unqualified, and where imports are checked. >> >> - Some want modules in the specific pre-ES6 JavaScript style, where >> they can be any arbitrary JS value, and in the good old JavaScript >> tradition that checking doesn't matter. >> >> The current design (including the newest suggestions for imports) >> seems to please neither side, because it tries to be the former >> semantically, but wants to optimise for the latter syntactically. The >> main outcome is confusion. > > 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. You argue that throwing out checking is fine, i.e., you are arguing for the second goal, and against the first. But others disagree. >> - Either we think "real" modules are an improvement, and checking is >> important. Then the model and the syntax should be consistent about >> that. Moreover, checking needs to consistently apply, no matter how a >> module and its components are defined or accessed. >> >> - Or we come to the conclusion that supporting the legacy singleton >> export model as a primary use case is a mandatory matter. Then we >> should drop attempts of building something in/semi-compatible, and >> limit innovation to making export and import declarative, and >> designing a loader API. > > 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".) > >> Quite honestly, I rather have no import checking than checking that >> only applies in some syntactic cases -- because that gives a false >> sense of security, harms refactoring, and/or encourages overuse of >> unqualified imports, hampering readability. > > 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? No, the importers have no choice, they have to go with whatever the module provider picked. You cannot turn on checking on the use site alone, because it will lack the necessary static information from the definition site. Only "real" modules can provide that information, because only their definitions are sufficiently structured. That is fundamentally so. The hybrid, best of both worlds approach you seem to have in mind is technically impossible, unfortunately. /Andreas _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
