Static Module Resolution

[John J Barton]

On Sat, Jun 30, 2012 at 11:24 AM, Kevin Smith <khs4473 at gmail.com> wrote:

> 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).
>

Just define the order of execution between ES6 and pre-ES6 to run legacy.js
first.

The pre-ES systems mostly rely on running the 'outer' function as a meaning
of 'declaring' exports.  So when you load AMD modules the define() call
runs and recursively loads dependents. Similarly require('legacy.js') has
to run the line you wrote above so the exports.g is defined by the time we
return.

Working out the mix and migration strategies is important.


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

One part of your logic is flawless: we can't have pure static module
resolution if some of the modules are based on pre-ES dynamic logic.
 However, that does not say anything about ES modules.


jjb


>
> - Kevin
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120630/1efbfbce/attachment.html>