1

Does the standardization of __proto__ in ES2015 negate the need for Object.getPrototypeOf?

Ben Aston
  • 53,718
  • 65
  • 205
  • 331
  • Wouldn't this question be more appropriate for http://programmers.stackexchange.com? – CodingGorilla Mar 17 '16 at 13:10
  • My question is: do `__proto__` and `Object.getPrototype` of expose exactly the same functionality? – Ben Aston Mar 17 '16 at 13:14
  • @CodingGorilla when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) – gnat Mar 17 '16 at 13:17
  • @gnat I wasn't suggesting cross-posting, I was suggesting that it be removed from SO and re-posted on programmers, it just seems more of an appropriate site for this sort of question. – CodingGorilla Mar 17 '16 at 13:21

1 Answers1

7

Do __proto__ and Object.getPrototype of expose exactly the same functionality?

No. .__proto__ only works on objects that inherit from Object.prototype. And Object.getPrototype doesn't allow to mutate the prototype.

Does the standardization of __proto__ in ES2015 negate the need for Object.getPrototypeOf?

You've got it backwards. ES5 Object.getPrototypeOf and ES6 Object.setPrototypeOf completely negate the need to ever use __proto__.

The Object.prototype.__proto__ accessor property is only standardised in ES6 for backwards compatibility and interoperability between implementations that need it. It's explictly marked as a web legacy feature. Check the note on Annex B ("…legacy features [for] web browser based ECMAScript implementations. [They] have […] undesirable characteristics and […] would be removed from this specification [if not used] by large numbers of existing web pages […]. Programmers should not use or assume the existence of [them] when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features.")

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • You seem to say there's never a need to use `__proto__`. Your position is supported by your Annex B quotation and also by MDN's warning at [MDN proto](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto). However, that same page shows good mobile browser support, whereas [MDN getPrototypeOf](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/getPrototypeOf) shows question marks for mobile browser support. So if a project needs mobile browser support, couldn't it be preferable to use `__proto__` in that case? – Marcus Sep 18 '17 at 17:37
  • 1
    @Marcus No. It would preferable to use an `Object.getPrototypeOf` polyfill (that is implemented using `__proto__`) to support old browsers. Btw, a question mark means "nobody has found out the earliest version with support and entered it into the table", not "bad support". I even would question the unanimous "Yes" there, surely some early mobile browsers did not implement `__proto__`. In any case, `Object.getPrototypeOf` is supported by every ES5 engine, and you'll have a bunch of other problems in older (ES3) ones anyway. – Bergi Sep 18 '17 at 18:16
  • I have to say, I love the ease in which we can write `const a = {}; const b = { __proto__: a }`. I wish it would be un-deprecated. :) – trusktr Apr 15 '19 at 21:24
  • @trusktr `const b = Object.setPrototypeOf({}, a)` or `const b = Object.assign(Object.create(a), {})` isn't that much worse. There once also was a [proposal for a prototype operator](http://web.archive.org/web/20160404123540/http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator): `const b = a <| {}` – Bergi Apr 15 '19 at 21:59