jeena/en.javascript.info
1
0
Fork 0
Code Issues Pull requests Projects Packages Wiki Activity Actions

Merge branch 'master' into patch-43

Browse source
This commit is contained in:
Ilya Kantor 2019-09-18 12:44:52 +03:00 • committed by GitHub
commit adf7fb4fec
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 6 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
1-js/08-prototypes/04-prototype-methods/article.md
View file

@ -82,7 +82,7 @@ Why was `__proto__` replaced by the functions `getPrototypeOf/setPrototypeOf`? T
```warn header="Don't change `[[Prototype]]` on existing objects if speed matters"
Technically, we can get/set `[[Prototype]]` at any time. But usually we only set it once at the object creation time, and then do not modify: `rabbit` inherits from `animal`, and that is not going to change.
And JavaScript engines are highly optimized for this. Changing a prototype "on-the-fly" with `Object.setPrototypeOf` or `obj.__proto__=` is a very slow operation, it breaks internal optimizations for object property access operations. So evade it unless you know what you're doing, or JavaScript speed totally doesn't matter for you.
And JavaScript engines are highly optimized for this. Changing a prototype "on-the-fly" with `Object.setPrototypeOf` or `obj.__proto__=` is a very slow operation, it breaks internal optimizations for object property access operations. So avoid it unless you know what you're doing, or JavaScript speed totally doesn't matter for you.
```
## "Very plain" objects [#very-plain]
@ -108,17 +108,17 @@ That shouldn't surprise us. The `__proto__` property is special: it must be eith
But we didn't *intend* to implement such behavior, right? We want to store key/value pairs, and the key named `"__proto__"` was not properly saved. So that's a bug!
Here the consequences are not terrible. But in other cases, we may be assigning object values, then the prototype may indeed be changed. As the result, the execution will go wrong in totally unexpected ways.
Here the consequences are not terrible. But in other cases we may be assigning object values, and then the prototype may indeed be changed. As the result, the execution will go wrong in totally unexpected ways.
What's worst -- usually developers do not think about such possibility at all. That makes such bugs hard to notice and even turn them into vulnerabilities, especially when JavaScript is used on server-side.
What's worse -- usually developers do not think about such possibility at all. That makes such bugs hard to notice and even turn them into vulnerabilities, especially when JavaScript is used on server-side.
Unexpected things also may happen when assigning to `toString` -- that's a function by default, and other built-in methods.
Unexpected things also may happen when assigning to `toString`, which is a function by default, and to other built-in methods.
How to evade the problem?
How to avoid the problem?
First, we can just switch to using `Map`, then everything's fine.
But `Object` also can serve us well here, because language creators gave a thought to that problem long ago.
But `Object` also can serve us well here, because language creators gave thought to that problem long ago.
The `__proto__` is not a property of an object, but an accessor property of `Object.prototype`: