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: For clarity, manipulate _record_.[[Field]] rather than its alias #2947

Merged
merged 3 commits into from
Feb 13, 2023

Conversation

gibson042
Copy link
Contributor

Even though aliases are "reference-like" per Algorithm Conventions, it is not always clear in context that steps like "append <value> to listAlias" and "remove <value> from listAlias" affect the Record whose field is referenced by listAlias—and to be honest, the presence of many such aliases doesn't even contribute very much in my opinion. But this PR is still split into meaningful commits in case the editors disagree with a subset of its changes.

Another alternative option would be to keep the aliases but make their behavior more explicit, as is done like "Let S be a reference to the list of waiters in WL." in RemoveWaiters.

spec.html Outdated
@@ -40423,7 +40418,7 @@ <h1>Map.prototype.set ( _key_, _value_ )</h1>
1. Return _M_.
1. If _key_ is *-0*<sub>𝔽</sub>, set _key_ to *+0*<sub>𝔽</sub>.
1. Let _p_ be the Record { [[Key]]: _key_, [[Value]]: _value_ }.
1. Append _p_ to _entries_.
1. Append _p_ to _M_.[[MapData]].
Copy link
Contributor

@bakkot bakkot Jan 10, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might as well get rid of the _entries_ aliases entirely at this point (in this and subsequent algorithms); it seems weirder to refer to the same value in two different ways in the same algorithm.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Copy link
Contributor

@bakkot bakkot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM other than comment

Copy link
Member

@michaelficarra michaelficarra left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bakkot bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Feb 13, 2023
@ljharb ljharb merged commit 6aa7ba8 into tc39:main Feb 13, 2023
jmdyck added a commit to jmdyck/ecma262 that referenced this pull request Feb 16, 2023
PR tc39#2947 changed 6 occurrences of:
`the element of _execution_.[[EventsRecords]] whose ...`
to:
`the Agent Events Record of _execution_.[[EventsRecords]] whose ...`

But there were also 2 pre-existing occurrences of
`the Agent Events Record in _execution_.[[EventsRecords]] whose ...`
with "in" rather than "of", in {Enter,Leave}CriticalSection.

To achieve consistency, this commit changes the latter (with "in")
to match the former (with "of").
Roughly speaking, this conforms to PR tc39#2941.
ljharb pushed a commit to jmdyck/ecma262 that referenced this pull request Feb 17, 2023
PR tc39#2947 changed 6 occurrences of:
`the element of _execution_.[[EventsRecords]] whose ...`
to:
`the Agent Events Record of _execution_.[[EventsRecords]] whose ...`

But there were also 2 pre-existing occurrences of
`the Agent Events Record in _execution_.[[EventsRecords]] whose ...`
with "in" rather than "of", in {Enter,Leave}CriticalSection.

To achieve consistency, this commit changes the latter (with "in")
to match the former (with "of").
Roughly speaking, this conforms to PR tc39#2941.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial change ready to merge Editors believe this PR needs no further reviews, and is ready to land.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants