Static Module Resolution

[Kevin Smith]

Thanks Dave, for writing your blog post - it definitely cleared up some
things for me (macros in particular).  If there were no module systems
already in place, I would definitely agree with static resolution.
 However, it seems to me that ES6 modules (in whatever form they take) are
going to have to coexist and interoperate with pre-ES6 modules that export
dynamically.

Consider this scenario in a server-side environment like Node:

    // main.js
    import g from "./legacy.js";

    // legacy.js
    exports.g = function() { return "hello world"; }

The exports of "legacy.js" are dynamic:  there's no way to know that "g" is
exported until we execute the script.  In order to avoid a compile-time
binding error in "main.js", we have to know that "g" is exported from
"legacy.js".  And in order to do that, we have to execute "legacy.js".

So we have a situation where "legacy.js" must be executed PRIOR TO
INITIALIZING "main.js".  This violates the order-of-execution semantics for
both ES6 modules and for Node modules (and all "require"-based module
systems, for that matter).

If this logic is correct (is it?), then I don't see how pure static module
resolution is practical.

- Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120630/bdc1a81e/attachment.html>