Re: Re-exporting imports and CreateImportBinding assertions
And to close the loop: rev37 makes clear that ResolveExport() will follow
re-exported import bindings to discover the module in which they
originated. This makes all the assertions correct. In my example, it means
that the CreateImportBinding call in 'a' is:
CreateImportBinding(x, 'c', x)
Thanks to Allen for the swift turnaround of these changes.
On Thu, Apr 2, 2015 at 8:17 AM, Adam Klein ad...@chromium.org wrote:
I've added this to a few bugs on the bug-tracker:
https://bugs.ecmascript.org/show_bug.cgi?id=4184 (CreateImportBinding)
https://bugs.ecmascript.org/show_bug.cgi?id=4244 (GetExportedNames and
ResolveExport)
On Wed, Apr 1, 2015 at 4:31 PM, Adam Klein ad...@chromium.org wrote:
I have a question about CreateImportBinding(N, M, N2) (where N is the
name to create in the importing module, and M is a module which exports N2).
Step 4 of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding
is the following assertion
Assert: When M.[[Environment]] is instantiated it will have a direct
binding for N2.
What about the case were M is simply re-exporting an import? Consider:
-
module 'a':
import { x } from 'b';
-
module 'b':
import { x } from 'c';
export { x };
-
module 'c':
export let x = 42;
-
In this case, when running CreateImportBinding(x, 'b', x) in module 'a',
the assertion fails, as x in 'b' is an immutable indirect binding (itself
created by CreateImportBinding).
Is there a need for this assert I'm missing? I don't think skipping over
this assert, or removing direct from its wording, will cause any
problems. Also, the term direct binding is not defined anywhere that I
can find, except as the negation of the indirect binding created by
CreateImportBinding.
Note that there's a similar issue in ResolveExport: step 4.a.i of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport
asserts that resolved exports found in [[LocalExportEntries]] are leaf
bindings (another term that goes undefined), where by the usual CS
definition of leaf the assertion would be false for x in 'b' (when
resolved from 'a').
- Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Re-exporting imports and CreateImportBinding assertions
I've added this to a few bugs on the bug-tracker:
https://bugs.ecmascript.org/show_bug.cgi?id=4184 (CreateImportBinding)
https://bugs.ecmascript.org/show_bug.cgi?id=4244 (GetExportedNames and
ResolveExport)
On Wed, Apr 1, 2015 at 4:31 PM, Adam Klein ad...@chromium.org wrote:
I have a question about CreateImportBinding(N, M, N2) (where N is the name
to create in the importing module, and M is a module which exports N2).
Step 4 of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding
is the following assertion
Assert: When M.[[Environment]] is instantiated it will have a direct
binding for N2.
What about the case were M is simply re-exporting an import? Consider:
-
module 'a':
import { x } from 'b';
-
module 'b':
import { x } from 'c';
export { x };
-
module 'c':
export let x = 42;
-
In this case, when running CreateImportBinding(x, 'b', x) in module 'a',
the assertion fails, as x in 'b' is an immutable indirect binding (itself
created by CreateImportBinding).
Is there a need for this assert I'm missing? I don't think skipping over
this assert, or removing direct from its wording, will cause any
problems. Also, the term direct binding is not defined anywhere that I
can find, except as the negation of the indirect binding created by
CreateImportBinding.
Note that there's a similar issue in ResolveExport: step 4.a.i of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport
asserts that resolved exports found in [[LocalExportEntries]] are leaf
bindings (another term that goes undefined), where by the usual CS
definition of leaf the assertion would be false for x in 'b' (when
resolved from 'a').
- Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re-exporting imports and CreateImportBinding assertions
I have a question about CreateImportBinding(N, M, N2) (where N is the name
to create in the importing module, and M is a module which exports N2).
Step 4 of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createimportbinding
is the following assertion
Assert: When M.[[Environment]] is instantiated it will have a direct
binding for N2.
What about the case were M is simply re-exporting an import? Consider:
-
module 'a':
import { x } from 'b';
-
module 'b':
import { x } from 'c';
export { x };
-
module 'c':
export let x = 42;
-
In this case, when running CreateImportBinding(x, 'b', x) in module 'a',
the assertion fails, as x in 'b' is an immutable indirect binding (itself
created by CreateImportBinding).
Is there a need for this assert I'm missing? I don't think skipping over
this assert, or removing direct from its wording, will cause any
problems. Also, the term direct binding is not defined anywhere that I
can find, except as the negation of the indirect binding created by
CreateImportBinding.
Note that there's a similar issue in ResolveExport: step 4.a.i of
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-resolveexport
asserts that resolved exports found in [[LocalExportEntries]] are leaf
bindings (another term that goes undefined), where by the usual CS
definition of leaf the assertion would be false for x in 'b' (when
resolved from 'a').
- Adam
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
