Permalink
Browse files

Merge pull request #1349 from younesherlock/patch-1

Fix typo
  • Loading branch information...
getify committed Sep 16, 2018
2 parents 01ecb8d + 23412d2 commit 0cc17c53ff772e20dfd6a7072c965df2486116e8
Showing with 1 addition and 1 deletion.
  1. +1 −1 this & object prototypes/ch5.md
@@ -321,7 +321,7 @@ Recall the discussion from earlier about the `.constructor` property, and how it
This is just unfortunate confusion. In actuality, the `.constructor` reference is also *delegated* up to `Foo.prototype`, which **happens to**, by default, have a `.constructor` that points at `Foo`.
It *seems* awfully convenient that an object `a` "constructed by" `Foo` would have access to a `.constructor` property that points to `Foo`. But that's nothing more than a false sense of security. It's a happy accident, almost tangentially, that `a.constructor` *happens* to point at `Foo` via this default `[[Prototype]]` delegation. There's actually several ways that the ill-fated assumption of `.constructor` meaning "was constructed by" can come back to bite you.
It *seems* awfully convenient that an object `a` "constructed by" `Foo` would have access to a `.constructor` property that points to `Foo`. But that's nothing more than a false sense of security. It's a happy accident, almost tangentially, that `a.constructor` *happens* to point at `Foo` via this default `[[Prototype]]` delegation. There are actually several ways that the ill-fated assumption of `.constructor` meaning "was constructed by" can come back to bite you.
For one, the `.constructor` property on `Foo.prototype` is only there by default on the object created when `Foo` the function is declared. If you create a new object, and replace a function's default `.prototype` object reference, the new object will not by default magically get a `.constructor` on it.

0 comments on commit 0cc17c5

Please sign in to comment.