-
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
Normative: move __proto__ out of annex b #2125
Conversation
9a7d36d
to
3572cef
Compare
Is it still optional for non-web platforms? |
@Jack-Works |
I don't find what benefit we can get from the |
@Jack-Works we have previous consensus to move items out of annex b and into the main spec where possible. |
spec.html
Outdated
</emu-clause> | ||
</emu-clause> | ||
|
||
<emu-clause id="sec-object.prototype.__defineGetter__"> |
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.
Why would we want the legacy define methods to be normative required??
The vast majority of annex b should remain normative optional, and anything that’s definitely only needed on the web imo should stay in annex b.
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.
🤷 no one had any reason to make these ones optional, unlike the __proto__
accessor. even quickjs and xs implement __defineGetter__
and whatnot.
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.
#1JS
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 reason - one I hold for many parts of Annex B - is that these things are bad and should never have existed, and more importantly, are not universally used.
__proto__
is used everywhere, in non-web code as well. __defineGetter_
and friends are not.
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.
__defineGetter__
and friends are sufficiently widely used that any implementation intending to run JavaScript as it exists in the world needs to implement them. Writing down those things is the whole point of having a standard. I don't see the point of omitting them.
Incidentally, that's also what I understood to be consensus when this was discussed in plenary.
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.
@ljharb I know the history of __proto__
. The point I was making is that there's parts of the JavaScript standard that we now, in hindsight, consider to be mistakes (even outside of Annex B). Whether they were intentionally designed or organically became part of the standard after first becoming a de facto standard doesn't matter. It feels weird to special-case features just because they used to be in Annex B.
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.
FWIW, I wish __proto__
was completely removed from specs, and from any engine. To date it caused more troubles than it supposed to solve, and both Object
and Reflect
have dedicated methods that replace it already.
The only usage I kinda think is reasonable, is for one-off literals creation, and literally nothing else: {__proto__: Shared, counter: 0}
... that's it.
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.
@ljharb so I just need to add a note that says we don't like them?
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 __proto__
accessor and other %Object.prototype% __
‑prefixed and suffixed properties should remain in Annex B, as they have the much saner {Object,Reflect}.{defineProperty,getOwnPropertyDescriptor,getPrototypeOf,setPrototypeOf}
alternatives.
In fact, in some old engines the __lookup*__
functions will return an accessor even if it’s shadowed by a data property.
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.
@mathiasbynens that's totally true, but the entire purpose of Annex B was always "this is a special case we don't want in the actual language, and we don't want people using, but is here for web compat". In other words, I'm saying that "being in Annex B" is already being special-cased, and i don't want that indiscriminately lost.
@devsnek just like "normative optional" is a special tag, i'd want some kind of "deprecated" tag, that referenced a big scary note saying these are bad and if you use them you should feel bad, yes.
This PR currently has unresolved issues and merge conflicts that prevent merging it. Also, the lint issues have been fixed in tc39/ecmarkup#239. |
FWIW – we held out on supporting |
in case it was not clear, they are still normative optional. |
Since this has several merge conflicts, moves other legacy |
I will update this if there is reason to do so (after we discuss it at TC39). There is no reason to open another PR. |
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.
Direct removal is not the best solution, we should seek a better one.
Summarizing today's consensus:
where "icky" conveys the existing sentiment for everything in Annex B found here:
Additionally, there was interest expressed in noting which optional things were encouraged to be implemented when an engine's goals are interop; versus which "icky" things are discouraged for practitioners to use. (I'll update the PR's consensus label when it matches that consensus) |
Will update shortly... |
@devsnek Feel free to use my #2175 |
Commenting on the summary from @ljharb, ECMA-402 contains text which appears to define its use of "normative optional" to mean "Annex B":
With this PR, TC39 would be using "normative optional" for the first time. It would be preferable to have a consistent definition of "normative optional", if possible, between ECMA-262 and ECMA-402. |
Alternatively, perform the move to use “normative optional” in a future PR and keep the legacy properties on |
3572cef
to
c27a2e0
Compare
e5ebd15
to
d952b3b
Compare
- co-opts prose from Annex B description - dfn legacy and add emu-not-ref where appropriate - use dash in IDs - don't <dfn> legacy; clauses are what is legacy Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Gus Caplan <me@gus.host> Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Dyck <jmdyck@ibiblio.org>
d952b3b
to
ed383ac
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 good. (I'll try not to think about this any more.)
- co-opts prose from Annex B description - dfn legacy and add emu-not-ref where appropriate - use dash in IDs - don't <dfn> legacy; clauses are what is legacy Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Gus Caplan <me@gus.host> Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Dyck <jmdyck@ibiblio.org>
ed383ac
to
1d70aa7
Compare
🎉 |
- co-opts prose from Annex B description - dfn legacy and add emu-not-ref where appropriate - use dash in IDs - don't <dfn> legacy; clauses are what is legacy Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Ficarra <mficarra@shapesecurity.com>
Co-authored-by: Gus Caplan <me@gus.host> Co-authored-by: Jordan Harband <ljharb@gmail.com> Co-authored-by: Michael Dyck <jmdyck@ibiblio.org>
No description provided.