Skip to content

Conversation

bakkot
Copy link
Contributor

@bakkot bakkot commented Aug 15, 2021

#2483 proposes to change a few occurrences of "TypedArray object" to "TypedArray". (There were some usages of the latter form already.) That seems better, so we might as well do that everywhere it makes sense to do so.

I've changed most uses of "an X object" to be "an X", with the following exceptions:

  • when referring to an exotic object in a context which emphasizes its exotic nature, I've left it as "an X exotic object"
  • "Set object" remains as-is, to distinguish from the built-in type of the same name (I've also added a note calling attention to this)
  • "Error object" and variants remain as-is, to make it clear it's talking about a value rather than an exceptional condition
  • the various boxed primitive types remain "a Boolean object" (etc), to distinguish from the primitives
  • "RegExp object" remains as-is to distinguish it from RegExp literals (this one I could go either way)
  • "Proxy object" remains as-is because it read a little better to me (this one I could go either way)

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.

I don't love "Date object" to "Date", but it's fine.

spec.html Outdated
@@ -11945,7 +11945,7 @@ <h1>Objectives</h1>

<p>This specification does not make any guarantees that any object will be garbage collected. Objects which are not live may be released after long periods of time, or never at all. For this reason, this specification uses the term "may" when describing behaviour triggered by garbage collection.</p>

<p>The semantics of WeakRef and FinalizationRegistry objects is based on two operations which happen at particular points in time:</p>
<p>The semantics of WeakRefs and FinalizationRegistrys is based on two operations which happen at particular points in time:</p>
Copy link
Member

Choose a reason for hiding this comment

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

oof, FinalizationRegistrys

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ehhh I will just fix that.

Copy link
Member

Choose a reason for hiding this comment

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

lol that's also awkward if FInalizationRegistry is a dfn tho - making this "FinalizationRegistry objects" to avoid this problem was an explicit editorial review item for the weakref proposal :-p

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Neither FinalizationRegistrys nor FinalizationRegistries will auto-link currently, so we might as well go with the better one.

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
<p>The semantics of WeakRefs and FinalizationRegistrys is based on two operations which happen at particular points in time:</p>
<p>The semantics of a WeakRef and a FinalizationRegistry are based on two operations which happen at particular points in time:</p>

?

Copy link
Member

Choose a reason for hiding this comment

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

I'm concerned about both automatic linking and also natural pluralization; i suppose if ecmarkup could detect y → ies then it's not a big deal, but it makes it awkward to speak about out loud.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i suppose if ecmarkup could detect y → ies then it's not a big deal

I was thinking I'd just allow dfn to specify pluralizations explicitly.

it makes it awkward to speak about out

Sorry, what becomes awkward?

Copy link
Member

Choose a reason for hiding this comment

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

ys obviously, when spoken aloud, nobody will come up with the spelling; the ies one just seems weird to me even though also obviously, the pluralization of registry is registries, it's weird when it's a camelcased thing.

not a strong opinion, it's just weird :-)

Copy link
Member

Choose a reason for hiding this comment

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

I think FinalizationRegistrys is fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Rebased on #2492, so now the plural FinalizationRegistrys should link.

@ljharb ljharb mentioned this pull request Aug 17, 2021
@michaelficarra michaelficarra added editor call to be discussed in the next editor call and removed editor call to be discussed in the next editor call labels Aug 18, 2021
@bakkot bakkot added the ready to merge Editors believe this PR needs no further reviews, and is ready to land. label Aug 24, 2021
@bakkot
Copy link
Contributor Author

bakkot commented Aug 24, 2021

Ugh, hold off merging for a sec, I just noticed a typo

edit: ok fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
establishes editorial conventions 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.

3 participants