On Mon, Jan 27, 2014 at 3:24 PM, Marius Gundersen <gunder...@gmail.com>wrote:
> > On Jan 28, 2014 12:14 AM, "John Barton" <johnjbar...@google.com> wrote: > > > > > > > > > > On Mon, Jan 27, 2014 at 2:50 PM, Sam Tobin-Hochstadt < > sa...@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@1.6 and jQuery needs X@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 <johnjbar...@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 <dher...@mozilla.com> > wrote: > >> >> > >> >> On Jan 27, 2014, at 2:18 PM, Marius Gundersen <gunder...@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@mozilla.org > >> >> https://mail.mozilla.org/listinfo/es-discuss > >> > > >> > > >> > > >> > _______________________________________________ > >> > es-discuss mailing list > >> > es-discuss@mozilla.org > >> > https://mail.mozilla.org/listinfo/es-discuss > >> > > > > _______________________________________________ > > es-discuss mailing list > > es-discuss@mozilla.org > > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss