multiple modules with the same name

Sam Tobin-Hochstadt samth at cs.indiana.edu
Mon Jan 27 14:50:11 PST 2014


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.

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
>


More information about the es-discuss mailing list