ES Modules: suggestions for improvement

[Kevin Smith]

>
>    <script src="/assets/add_blaster.js">
>    <script>
>    module main {
>      import go from "add_blaster";
>      console.log(go(4,5));
>    }
>    </script>
>

That's *not* what I'd call a "forward-compatible" solution since you still
have to use the script tag prior to importing.  What's needed is a way to
tell the loader that "add_blaster" can be fetched from
"/assets/add_blaster.js".

I believe that's what James is referring to: a declarative set of mappings
that inform the loader where to fetch certain modules from.  Creating a
custom loader which overrides the default loader's resolve behavior is
going to be too much work for this simple use case.  That's the argument,
anyway.  If it's not difficult, then I think we as a community need to see
examples of how that would work.

It seems that a better way to enable forward-compatibility would be to
provide an imperative way to set the exports of the current module:

    if (this.System)
      System.setCurrentModuleExports({ ... }); // A shorter name, of course!

The "forward-compatible" module is then relieved of the necessity of naming
itself using some arbitrary module name (which would obviously pollute the
global module namespace: not acceptable).

Trying to keep this message short, but it seems to me that once we allow
the possibility of custom loader behavior (even as simple as declaratively
remapping URLs), then the arguments for static import/export start to fall
apart.  In order to keep the supposed benefits of static analysis, our
tools (i.e. IDE) are going to have to be aware of that custom loading
behavior to continue to be useful.  And if modules are dynamically injected
into the module namespace with System.set, then static analysis (and the
typo-checking that is deemed so important) is completely "out-the-window".

Does this indicate that the static analysis arguments are on shaky ground?

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