-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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: remove legacy intrinsics #2056
Conversation
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 Well-Known Intrinsics clause has (what might be read as) two definitions of "well-known intrinsics":
- built-in objects that are explicitly referenced by the algorithms of this specification, and
- the objects listed in the table "Well-Known Intrinsic Objects".
Currently, these definitions are more or less in agreement, but with this PR, they very much disagree.
E.g., is %ArrayBuffer.prototype% a well-known intrinsic? It's explicitly referenced in AllocateArrayBuffer
, but it doesn't appear in the table.
What about %AsyncFunction%? It's in the table, but isn't explicitly referenced by any algorithm. (Several implicit references though.)
It's possible that the first 'definition' isn't meant to be a definition, but is just a statement of something that is true of well-known intrinsics, but is also true of other intrinsics. In which case, it's not a very helpful statement.
Either way, this PR should change some prose in the Well-Known Intrinsics clause.
spec.html
Outdated
@@ -26488,7 +25947,6 @@ <h1>Boolean.prototype</h1> | |||
<h1>Properties of the Boolean Prototype Object</h1> | |||
<p>The Boolean prototype object:</p> | |||
<ul> | |||
<li>is the intrinsic object <dfn>%BooleanPrototype%</dfn>.</li> |
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.
With this line removed, there's no explicit statement that the phrases "the Boolean Prototype Object" and "%Boolean.prototype%" denote the same object. While this equivalence might seem obvious given the similar wording, I don't think it should be left implicit.
Some possible solutions:
- Just reinstate the line.
- Leave the line out, and change:
<p>The Boolean prototype object:</p>
to something like:
<p>The Boolean prototype object (i.e., %Boolean.prototype%):</p>
or
<p>%Boolean.prototype% (the Boolean prototype object):</p>
(or maybe change the clause heading instead). - Leave the line out, and replace all occurrences of "the Boolean Prototype Object" with "%Boolean.prototype%". (This would probably be clearer as a separate PR, and might also address the equivalence of "the Foo constructor" and "%Foo%", which is not touched by this PR.)
(Ditto all of the above for the other similar removals.)
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.
How is it implicit at all? It's the object on Boolean.prototype
, Boolean
is %Boolean%
.
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.
Sorry, when you say:
It's the object on
Boolean.prototype
you mean that the phrase "the Boolean prototype object" denotes (the initial value of) Boolean.prototype
, right?
I agree that that's the intent, but this PR doesn't say so. I'm not saying people won't figure it out, I'm saying there's no reason it should be something they need to figure out.
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'm saying that %Boolean.prototype%
is already in the spec as "the original value of the prototype
property on %Boolean%
" - so perhaps just the sentence here needs to be updated, since it's currently a tautology?
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'm saying that
%Boolean.prototype%
is already in the spec as "the original value of theprototype
property on%Boolean%
"
Oh, okay. Well, I agree that that's in the spec, but I don't see how that answers my original point.
- so perhaps just the sentence here needs to be updated, since it's currently a tautology?
I agree that's currently a tautology. How would you update it? Maybe just demote it to a Note?
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 don't think it needs even a note; just making sure that "the Boolean Prototype object" is also noted somewhere as "the value of .prototype
on %Boolean%
should suffice?
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.
just making sure that "the Boolean Prototype object" is also noted somewhere as "the value of
.prototype
on%Boolean%
should suffice?
Okay, I'm not sure how we got here, but yes, this aligns with two of the solutions I originally suggested.
And the third solution was to eliminate the phrase "the Boolean Prototype object". Does the spec benefit from introducing that phrase, rather than just saying "%Boolean.prototype%" (or Boolean.prototype
, suitably qualified)?
350ca3a
to
1dd2709
Compare
To me this includes every object in the entire spec, which includes, eg, |
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 think we should keep the <dfn>
s for %*.prototype%
to keep auto‑linking working.
See also:
spec.html
Outdated
@@ -26008,7 +25473,6 @@ <h1>Object.values ( _O_ )</h1> | |||
<h1>Properties of the Object Prototype Object</h1> | |||
<p>The Object prototype object:</p> | |||
<ul> |
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.
<ul> | |
<ul> | |
<li>is the intrinsic object <dfn>%Object.prototype%</dfn>.</li> |
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.
When I posted #2056 (review), I thought that you’d add the <dfn>
s for the remaining %*.prototype%
properties without me needing to list them manually.
1dd2709
to
a77cc71
Compare
does the change make undeniable intrinsics deniable? |
@Jack-Works this PR is purely editorial (no observable change) except for an impact on Function.prototype.toString (which makes this PR accidentally normative, which means it won't land soon). Deniability is unrelated. |
Well, the impact on Also, I’m pretty sure that dotted intrinsics also count as well‑known intrinsic objects. |
@ExE-Boss as is, the PR is normative in the sense that it allows engines to omit more names. Another option is to tighten the toString requirement to require all names. "well-known" means it's in the table; I don't think dotted forms are in that category - and if they were, then the change to support the dotted notation was normative, because it then imposes the toString name requirement on every function. |
We could also keep the dotted function intrinsics in the Well‑Known Intrinsic Objects table until #2068 is resolved. |
Since tc39/ecma262#1376, the dotted form of intrinsic notation is preferred. Additionally, tc39/ecma262#2056 intends to remove these legacy intrinsics, once it is non-normative to do so. HTML has already been updated to no longer use them.
Since tc39/ecma262#1376, the dotted form of intrinsic notation is preferred. Additionally, tc39/ecma262#2056 intends to remove these legacy intrinsics, once it is non-normative to do so. HTML has already been updated to no longer use them.
Couldn't we technically just remove this whole table? Every intrinsic is already declared inline with the relevant definition via "is the %Xyz% intrinsic object" |
@devsnek i think it's useful for the table to exist for all the top-level intrinsics; but either way it'd be out of scope of this PR. |
This comment has been minimized.
This comment has been minimized.
a77cc71
to
d8b366b
Compare
This comment has been minimized.
This comment has been minimized.
spec.html
Outdated
@@ -36709,7 +36168,6 @@ <h1>Properties of the Set Constructor</h1> | |||
|
|||
<emu-clause id="sec-set.prototype"> | |||
<h1>Set.prototype</h1> | |||
<p>The initial value of `Set.prototype` is the intrinsic %SetPrototype% object.</p> |
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.
You eliminated this line, and the corresponding one for WeakSet.prototype
, which makes sense because they're tautologies now. But why just these two? There are about 20 others.
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.
#2131 should address these; i'll rebase this after that lands and clean it up.
d8b366b
to
f647a44
Compare
Since tc39/ecma262#1376, the dotted form of intrinsic notation is preferred. Additionally, tc39/ecma262#2056 intends to remove these legacy intrinsics, once it is non-normative to do so. HTML has already been updated to no longer use them.
All uses of these have been removed from HTML: - whatwg/webidl#898 - whatwg/html#5655 - whatwg/infra#316
f647a44
to
df824ef
Compare
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.
Looks okay to me.
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.
lgtm, long time in the making, congrats!
All uses of these have been removed from HTML: - whatwg/webidl#898 - whatwg/html#5655 - whatwg/infra#316
df824ef
to
9b5b0ca
Compare
All uses of these have been removed from HTML and 402:
Closes #2023. Closes #2124.