ES Modules: suggestions for improvement

James Burke jrburke at gmail.com
Wed Jun 27 12:37:37 PDT 2012


On Wed, Jun 27, 2012 at 11:56 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu> wrote:
> Then we can use the module like this:
>
>    System.load("add_blaster", function(ab) { return ab.go(4,5); })
>
> or, since we know that "add_blaster" is a local module:
>
>    let { go } = System.get("add_blaster");
>    go(9,10);
>
> or, if we put the call to `System.set` in the previous script tag, we
> can just do:
>
>    import go from "add_blaster";
>    go(2,2);
>
> At no point here did we have to write a module system.

This is not usually how we have found loading to be done in AMD.
'add_blaster' is usually not loaded before that import call is first
seen. Call this module foo:

   import go from "add_blaster";

The developer asks for foo first. foo is loaded, and parsed.
'add_blaster' is seen and then loaded and parsed (although not sure
how 'add_blaster' is converted to a path…):

add_blaster calls the runtime:

   System.set("add_blaster", { go : function(n,m) { return n + m; } });

What happens according to the current modules proposal?

Does an error get generated for foo's import line stating that
add_blaster does not export go, or are those checks optional, as David
Bruant suggests on another message in this thread?

My previous interaction on this list led me to believe that I would
have to construct a userland library to make sure I load and execute
the script that does System.set("add_blaster") before foo is parsed.

If that is true, then that is what is fueling my particular feedback
about the "eval deps, modify module, then eval module" feedback.


More information about the es-discuss mailing list