-
Notifications
You must be signed in to change notification settings - Fork 106
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
Editorial: Reference ECMA-262 RequireInternalSlot and string-concatenation #387
Conversation
Ideally it would be referenced and not duplicated, I’d think. |
Are there rules for which parts of ECMA-262 are safe to reference? I just don't want a target to be pulled out from under ECMA-402. |
I'd say every part - while we don't have a programmatic way to enforce it, renaming or removal of any abstract op generally requires checking downstream specs, including 402 and HTML. |
I'm in favor of referencing and reusing the most we can from 262. The idea of the abstractions in 262 are also to be reused by extensions. On the other side, we need to find a better tracking for referenced abstractions. I believe we might achieve that adding tests here in 402 for the parts we add into the glossary. WDYT? |
What would probably be most effective is adding tests in 262 that check 402 and html, that fail if any referenced ops no longer exist. |
I believe the tests should be in ECMA-402, but adding tests in ECMA-262 for known usages is fine too. My raw idea:
This avoids a vicious cycle if we actually need to change abstraction names. |
Sounds great. |
Updated to reference rather than duplicate. |
In numberformat.html, you changed |
Note that |
A bunch of algorithms were duplicating RequireInternalSlot, but I think it makes more sense to just use it. However, I don't know if it should be copied in (as I have here) or referenced with a new biblio entry.
Also, should we do the same for string-concatenation?