On May 21, 2015, at 2:48 PM, Park, Daejun wrote:
> [It might be already discussed, but I couldn't find it.]
>
> According to my understanding, the spec does not specify the behavior of
> sharing module's environment (more specifically Module Record) along multiple
> imports, but leaves it as implementation-dependent. If it is true, what is
> the rationale? Is there any possibility that different browser engines will
> have different behavior on this?
>
> For example, suppose that module 'lib' is imported both in module 'a' and
> module 'b', as follows:
>
> // lib.js
> var counter = 0;
> export function inc() { console.log(++counter); }
>
> // a.js
> import { inc } from 'lib'
> export function f() { inc(); }
>
> // b.js
> import { inc } from 'lib'
> export function g() { inc(); }
>
> // main.js
> import { f } from 'a'
> import { g } from 'b'
> f(); // 1
> g(); // 1 or 2 ???
>
> Then, the spec allows both cases:
> 1) a single environment of the module 'lib' is shared for module 'a' and 'b'
> 2) separate environments are used for each module 'a' and 'b'
> In case #1, g() outputs '2', while in case #2, g() outputs '1'.
>
> In the spec, HostResolveImportedModule(referencingModule, specifier) says
> that "multiple different referencingModule, specifier pairs may map to the
> same Module Record instance." So, for the above example, both behaviors are
> possible. While Node.js implements the case #1, is there any existing (or
> planned) implementation that implements the case #2?
The intent is that a single module source code resource corresponds to a single
Module Record, regardless of the access path that was used to identify the
resource. The quoted text from HostResolveImportedModule is saying that it is
ok to use more than one "path" to identify a specific resource and you will
still get the same Module Record. Conversely, "./a" referenced from two
different places in a directory structure might reference different source code
resources and hence yield different Module Records.
Ultimately, it's up to the implementation provided module loader to define the
interpretation of all such module references, but a rational expectation for
the example you provide is case #1
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
