On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen <gundersen at gmail.com>wrote:

>
> On Jan 28, 2014 12:14 AM, "John Barton" <johnjbarton at google.com> wrote:
> >
> >
> >
> >
> > On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt <
> samth at cs.indiana.edu> wrote:
> >>
> >> This is absolutely necessary for polyfilling.
> >>
> >> Imagine that some browser has an ok-but-not-complete implementation of
> >> the X library, but you want to use jQuery 17, which requires a better
> >> version.  You need to be able to replace X with a polyfilled update to
> >> X, and then load jQuery on top of that.
> >>
> >> Note that this involves indirect access in the same library (jQuery)
> >> to two versions of X (the polyfill and the browser version), which is
> >> why I don't think Marius's worry is fixable without throwing out the
> >> baby with the bathwater.
> >
> >
> > Guy Bedford, based on experiences within the requirejs and commonjs
> worlds, has a much better solution for these scenarios. (It's also similar
> to how npm works).
> >
> > Your jQuery should depend upon the name X, but you Loader should map the
> name X when loaded by jQuery to the new version in Loader.normalize(). The
> table of name mappings can be configured at run time.
> >
> > For example, if some other code depends on X at 1.6 and jQuery needs X at 1.7,
> they each load exactly the version they need because the normalized module
> names embed the version number.
>
> This seems to handle the scenario where two versions is wanted. This would
> probably also work in the scenario where a unique instance of the same
> version should be given to every module depending on it. This would be
> useful for unit tests, where a clean world is required for each tests. Or
> for unit test maybe a new realm should be used for each test.
>
> If a module is redefined with imperative code then an error should
> probably be thrown, or the promise could be rejected.
>


> But I don't think that would be good for DOM manipulation. If innerHTML is
> used to add a lot of markup and an existing module to the DOM, should an
> error be thrown?
>
In my opinion, attempting to overwrite a Loader's module entry would cause
an error yes.


> Should none of the other markup be added to the DOM?
>
Whatever DOM does is DOM's business.


> What would the error message look like to adequately indicate the source
> of the error?
>
`The module name ${moduleName} has already been defined.`

I don't suggest we try to issue an error message special to this
circumstance, such as "Adding a module via innerHTML is craziness".  We'll
just let folks work that part out themselves.

jjb


>  Marius Gundersen
>
> >
> > This is the proper solution, not one based on overwriting the module
> registry.   To be sure, because of the overhead loading code on slow
> networks these kinds of multi-version scenarios are less attractive in the
> browser, but the fix is the adapt the code.
> >
> > Guy's project has a bit more: https://github.com/guybedford/systemjs
> >
> > jjb
> >
> >>
> >>
> >> Sam
> >>
> >> On Mon, Jan 27, 2014 at 5:45 PM, John Barton <johnjbarton at google.com>
> wrote:
> >> > What is the use case for allowing registration different modules
> under the
> >> > same name? IMO should be an error.
> >> > jjb
> >> >
> >> >
> >> > On Mon, Jan 27, 2014 at 2:32 PM, David Herman <dherman at mozilla.com>
> wrote:
> >> >>
> >> >> On Jan 27, 2014, at 2:18 PM, Marius Gundersen <gundersen at gmail.com>
> wrote:
> >> >>
> >> >> > 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?
> >> >>
> >> >> It's important to be able to modify module registration for things
> like
> >> >> polyfilling. But that doesn't mean it's something people should do in
> >> >> general. Note that Jason only gave you an answer in the context of
> the basic
> >> >> module loader semantics; he didn't say what will happen in the HTML
> >> >> semantics. In particular, we can make it an error for there to be two
> >> >> definitions of the same module name in the same HTML, a la:
> >> >>
> >> >>   <script type="module" name="jquery" src="jquery1.js"></script>
> >> >>   <script type="module" name="jquery" src="jquery2.js"></script>
> >> >>
> >> >> I'm inclined to call that an error, and require imperative
> modifications
> >> >> of existing module registrations to use imperative code.
> >> >>
> >> >> Dave
> >> >>
> >> >> _______________________________________________
> >> >> es-discuss mailing list
> >> >> es-discuss at mozilla.org
> >> >> https://mail.mozilla.org/listinfo/es-discuss
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > es-discuss mailing list
> >> > es-discuss at mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> > _______________________________________________
> > 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/20140127/7eddd16c/attachment-0001.html>

On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen <gundersen at gmail.com>wrote:

> But I don't think that would be good for DOM manipulation. If innerHTML is
> used to add a lot of markup and an existing module to the DOM, should an
> error be thrown?

In my opinion, attempting to overwrite a Loader's module entry would cause
an error yes.


> Should none of the other markup be added to the DOM?

Whatever DOM does is DOM's business.


> What would the error message look like to adequately indicate the source
> of the error?

`The module name ${moduleName} has already been defined.`

I don't suggest we try to issue an error message special to this
circumstance, such as "Adding a module via innerHTML is craziness".  We'll
just let folks work that part out themselves.