On Mon, Jan 27, 2014 at 11:08 PM, Jason Orendorff <jason.orendorff at gmail.com
> wrote:

> On Mon, Jan 27, 2014 at 1:54 PM, Marius Gundersen <gundersen at gmail.com>
> wrote:
> > I didn't find anything in the spec on handling multiple modules with the
> > same name [...]
> > What should happen in such a scenario? Should existing modules be
> > replaced? Should an error be thrown? How would that work with the DOM?
> > Should it be a no-op, with no feedback to the user?
>
> Before a module is ever exposed to scripts, before its module body
> runs, it is first linked. This binds it permanently with the other
> modules it imports.
>
> After that, if you call loader.set(name, otherModule), that only
> changes the loader's module registry. It affects future module loads.
> It does not affect any modules already linked to the original module
> that you replaced. It does not affect any functions from that original
> module that are already on the stack.
>
> -j
>

So then there would be two versions of the same module, and a module could
get access to both these modules at the same time. For example, if ModuleB,
which depends on ModuleA is loaded and linked, and later ModuleA is
redefined, then ModuleC could depend on both ModuleB and ModueA, and would
get (indirect) access to two versions of ModuleA. Is this problem
preventable?

Marius Gundersen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140127/f40b562c/attachment.html>

So then there would be two versions of the same module, and a module could
get access to both these modules at the same time. For example, if ModuleB,
which depends on ModuleA is loaded and linked, and later ModuleA is
redefined, then ModuleC could depend on both ModuleB and ModueA, and would
get (indirect) access to two versions of ModuleA. Is this problem
preventable?