David Herman wrote:
In general, I would like to see more updates and more convergence regarding the
modules specification, as many of us are now aiming at a (seemingly) wildly
moving target.
Well, the standard isn't out yet, so to some degree this is part of the
process. But I take the blame for this stuff not happening sooner. I am
actively working on modules, and trying to nail this all down as soon as
possible.
I would like to defend Dave against Kevin's "wildly". Sam's writeup from
the minutes gives the history:
STH: Yes, that was the way, but there was a realization that much of the
earlier approach was flawed and these updates lead to revisions.
One important use case for modules is to configure module references, so
that libraries can import jQuery (for example), and get the appropriate
version of jQuery specified by the page. Further, it's desirable to be
able to use different code for the same library name in different
context. Originally, the modules proposal managed this via lexical
scope, as follows:
module M1 {
module jquery = "jquery.js";
module something = "something_that_uses_jquery.js"
}
module M2 {
module jquery = "zepto.js";
module something_else = "something_else_that_uses_jquery.js"
}
However, this has two major problems:
Inheriting scope across references to external files is potentially
confusing, and disliked by a number of people
Once we decided to share instances of the same module, the "parent
scope" of a module is no longer well-defined
Therefore, we abandoned the idea of inheriting scope across external
references. However, this had two consequences that we did not
immediately appreciate. First, we no longer had a method for managing
this configuration between module names and source code. Second, scoped
module names no longer had nearly as much use as originally.
Thus, Dave and I revisited the design, abandoning the use of lexical
scope for managing module names, and introducing module names that could
be configured on a per-Loader basis.
-----
Now, there's no "wildness" here (things too a while, OTOH). The main
trajectory is from second class modules with lexical scope and no
memoization of shared instance by MRL, to memoization for sharing, to
lose the nested lexical scope when modules are not inlined, to more
manageable module names that actually match existing practice pretty well.
(Oh, and we gave up on lexical-only all the way up, and kept the global
object as top scope, but (separate from modules _per se_) with a new,
single lexical contour populated by script elements based on
let/const/class/module bindings.)
That the default loader knows about pathnames and ".js" is a good thing
in my view. You want something else, write another loader.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
