On Jan 29, 2010, at 6:50 PM, Allen Wirfs-Brock wrote:
David and Sam, well done!
Lots of nits to pick and ideas to discuss but this makes it very
clear how a simple "static" (or 2nd class) module system could
nicely integrate into ECMAScript.
I wanted to mention that "second class" is not a bad thing, since
modules are static (source-level, prior to loading and compilation)
segregations of code with generally or mostly static dependencies.
Also, Sam and Dave's proposal reflects second class modules as
objects, so there is no iron curtain between second and first class --
but crucially, the system is static if you don't reflect a module as
an object, which makes it easier to use for common module chores.
Even the first-class alternative needs special forms such as import
"..." so that static analysis can arrange to prefetch needed
resources. This makes for tension between the static and dynamic
"poles", since an import in a deeply-nested if-then chain, at least in
the browser, must still have its module prefetched unconditionally to
avoid violating the run-to-completion execution model.
Of course, one can use XMLHttpRequest and a safe eval, or (let's hope)
a cleaner dynamic import function, in either a first- or second-class
system. But this seems to be an exceptional case, and the import ["A",
"B", ...] form in Sam&Dave's proposal covers the common fail-over/
fallback use-case without requiring random logic driving dynamic import.
Another observation: first-class-only modules tend to fall into the
first-class functions gravity well. We saw this in presentations from
Kris and Ihab at the TC39 meeting, with the |module point(x, y) {...}|
example, which closely resembled a named function expression. Nothing
wrong with module as lexical scope special form, but if it makes a
module constructor function, then it to some extent duplicates function.
We already have first-class functions, but so far we have had to rely
on the <script> tag, eval of XHR-loaded code, pre-deployment
translation tools, and other extraordinary measures in lieu of an
integrated module system. This is the way things are, for better or
worse. But it need not dictate how first-class (first-class-only) an
integrated system should be.
That JS developers have to "make do" via a combination of first-class
functions and dynamic loading methods, however important to support
downrev browsers, should not preclude static module systems from
being explored. Good to see this second-class module system
exploration, at last.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
