Re-exporting imports and CreateImportBinding assertions

Adam Klein adamk at chromium.org
Mon Apr 6 17:17:06 UTC 2015


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 <adamk at 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 <adamk at 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150406/a97f0262/attachment.html>


More information about the es-discuss mailing list