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? Should none
of the other markup be added to the DOM? What would the error message look
like to adequately indicate the source of the error?

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/20140128/f78efe84/attachment.html>

> 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? Should none
of the other markup be added to the DOM? What would the error message look
like to adequately indicate the source of the error?