-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Using __proto__
in object literals is not deprecated
#3014
Conversation
@bakkot Is this not the consensus of the discussion you are referring to? |
@smith558 as that screenshot says, the use of the |
Yeah, Could you explain to me what they mean by "proto syntax"? I understand the other 2 points but for me, those would be included under "proto syntax". |
By contrast, |
- [Object.getPrototypeOf(obj)](mdn:js/Object/getPrototypeOf) -- returns the `[[Prototype]]` of `obj`. | ||
- [Object.setPrototypeOf(obj, proto)](mdn:js/Object/setPrototypeOf) -- sets the `[[Prototype]]` of `obj` to `proto`. | ||
|
||
These should be used instead of `__proto__`. | ||
These should be used instead of `.__proto__`. |
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.
Change to obj.__proto__
? Clashes with above paragraph when it's referenced as obj.__proto__
rather.
I see. Thanks! I feel like Objects and Prototypes are very important concepts and a first-time reader may feel confused by seeing suggestions to "use" |
You mean that using |
The
__proto__
syntax (as opposed to the getter/setter) was moved out of Annex B in tc39/ecma262#2125. It's fine to use, and in fact is generally preferable toObject.create()
(because it makes it easier to set up other normal data properties, and because it's syntax rather than an API call).