-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Layering: Rename Module.Instantiate to Module.Link #1312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
devsnek
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't speak for the spec changes themselves but the name change is great 👍
|
If this change is made, it would also require downstream changes, e.g., to https://html.spec.whatwg.org/. cc @domenic |
|
I also like this name change. |
|
I've always been a fan of Legend of Zelda. 👍 |
spec.html
Outdated
| <p>A <dfn>Module Record</dfn> encapsulates structural information about the imports and exports of a single module. This information is used to link the imports and exports of sets of connected modules. A Module Record includes four fields that are only used when evaluating a module.</p> | ||
| <p>For specification purposes Module Record values are values of the Record specification type and can be thought of as existing in a simple object-oriented hierarchy where Module Record is an abstract class with concrete subclasses. This specification only defines a single Module Record concrete subclass named Source Text Module Record. Other specifications and implementations may define additional Module Record subclasses corresponding to alternative module definition facilities that they defined.</p> | ||
| <p>Module Record defines the fields listed in <emu-xref href="#table-36"></emu-xref>. All Module Definition subclasses include at least those fields. Module Record also defines the abstract method list in <emu-xref href="#table-37"></emu-xref>. All Module definition subclasses must provide concrete implementations of these abstract methods.</p> | ||
| <p>For specification purposes Module Record values are values of the Record specification type and can be thought of as existing in a simple object-oriented hierarchy where Module Record is an abstract class with both abstract and concrete subclasses. This specification defines the abstract subclass named Cyclic Module Record and its concrete subclass named Source Text Module Record. Other specifications and implementations may define additional Module Record subclasses corresponding to alternative module definition facilities that they defined.</p> <p>Module Record defines the fields listed in <emu-xref href="#table-36"></emu-xref>. All Module Definition subclasses include at least those fields. Module Record also defines the abstract method list in <emu-xref href="#table-37"></emu-xref>. All Module definition subclasses must provide concrete implementations of these abstract methods.</p> |
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
|
The name change seems good to me; I'm happy to see the positive reaction here. Let's discuss this in the November 2018 TC39 meeting. |
|
I was hoping we could land layering changes outside of plenary? |
|
Oh, sure, I'd be fine with landing this outside of plenary. Let's just not delay this longer than that. Editors, what do you think? |
|
We're fine with this change; will finish reviewing #1311 and will pull these in together. |
ljharb
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The diff for just the rename can be viewed here: linclark/ecma262@cyclic-mr-2...linclark:rename-instantiate
|
Ping on this change; I was hoping it would be pulled in together with #1311 per #1312 (comment) . |
|
@littledan this one won't be in 2019, and it'll need to be rebased as well (that will also help it be more easily reviewed, since it wasn't set up as a stacked PR) |
|
Rebase out for review at #1465 . Please let me know if you need anything else. |
|
To clarify, please do not open redundant PRs; either the PR author has to rebase it, or you can post a link to your branch, and this PR can updated by an editor with those commits. |
c910453 to
b7ba2f8
Compare
|
Oops, didn't realize I had write access to this branch. Rebased here. |
zenparsing
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes look good, and in general I like the name change. I'm curious about the churn that it might create for JS engine APIs, though.
Thoughts @ajklein? Other implementers?
|
I like the name change conceptually, so happy to see this move forward. I don't think that we'd change V8's C++ naming just because of this spec change; rather we'd use the new name if we had other reasons that the API needed changing. @GeorgNeis in case he agrees or disagrees |
|
Do you need anything else from me to review this patch? From #1312 (comment) , it sounds like implementation burden isn't a big issue here. |
2cbf848 to
4f13bc9
Compare
The terminology between WebAssembly and ES modules differs when it comes to instantiation, which causes some confusion for the integration of the two systems. Ideally, we wouldn't use the same term to mean two different things between the specs. After talking about it with multiple people, it seems like calling it "the linking phase" might be a better name for this phase anyway. Developers are often confused about what actually happens during instantiation and why it's separated from evaluation. I believe "linking" more clearly communicates the justification for this being its own phase.
The terminology between WebAssembly and ES modules differs when it comes to instantiation, which causes some confusion for the integration of the two systems. Ideally, we wouldn't use the same term to mean two different things between the specs. After talking about it with multiple people, it seems like calling it "the linking phase" might be a better name for this phase anyway. Developers are often confused about what actually happens during instantiation and why it's separated from evaluation. I believe "linking" more clearly communicates the justification for this being its own phase.
4f13bc9 to
05c7620
Compare
|
Is someone following up with other specs that currently use "Instantiate"? I'm thinking at least HTML, WebIDL, top-level-await and wasm/esm-integration. |
|
@Ms2ger I haven't done this yet; if you are interested in fixing these other specs, it would be greatly appreciated. |
* Update to current TLA draft. * Rename uninstantiated to unlinked. See <tc39/ecma262#1312>.
* Update to current TLA draft. * Rename uninstantiated to unlinked. See <tc39/ecma262#1312>.
The terminology between WebAssembly and ES modules differs when it comes to instantiation, which causes some confusion for the integration of the two systems. Ideally, we wouldn't use the same term to mean two different things between the specs.
After talking about it with multiple people, it seems like calling it "the linking phase" might be a better name for this phase anyway. Developers are often confused about what actually happens during instantiation and why it's separated from evaluation. I believe "linking" more clearly communicates the justification for this being its own phase.
Note: This depends on #1311. The relevant commit for this PR is the last one. Once #1311 is merged, I can rebase this to remove those commits.