Skip to content
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

Merged
merged 3 commits into from
Nov 20, 2019

Conversation

gibson042
Copy link
Contributor

@gibson042 gibson042 commented Nov 20, 2019

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?

@ljharb
Copy link
Member

ljharb commented Nov 20, 2019

Ideally it would be referenced and not duplicated, I’d think.

@gibson042
Copy link
Contributor Author

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.

@ljharb
Copy link
Member

ljharb commented Nov 20, 2019

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.

@leobalter
Copy link
Member

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?

@ljharb
Copy link
Member

ljharb commented Nov 20, 2019

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.

@leobalter
Copy link
Member

I believe the tests should be in ECMA-402, but adding tests in ECMA-262 for known usages is fine too.

My raw idea:

  • ECMA-402: Every build will check references in the glossary, failing if not found in ECMA-262.
  • ECMA-262: Every build will import the references from glossary files we mark (checkout repo's default branch and lookup). Instead of a failure, warn if new changes affect references.

This avoids a vicious cycle if we actually need to change abstraction names.

@ljharb
Copy link
Member

ljharb commented Nov 20, 2019

Sounds great.

@gibson042 gibson042 changed the title Editorial: Copy RequireInternalSlot from ECMA-262 Editorial: Reference ECMA-262 RequireInternalSlot and string-concatenation Nov 20, 2019
@gibson042
Copy link
Contributor Author

Updated to reference rather than duplicate.

@leobalter leobalter merged commit 0ab43d4 into tc39:master Nov 20, 2019
@sffc
Copy link
Contributor

sffc commented Dec 19, 2019

In numberformat.html, you changed .formatToParts, but not .format or .resolvedOptions. Is that intentional?

@sffc
Copy link
Contributor

sffc commented Dec 19, 2019

Note that .format uses UnwrapNumberFormat, which checks for [[InitializedNumberFormat]], whereas .formatToParts checks for that slot directly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants