Show internal prototype slot as [[prototype]] instead of __proto__
Reported by
a.d.be...@gmail.com,
Feb 28 2018
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.189 Safari/537.36 Vivaldi/1.95.1077.55 Steps to reproduce the problem: When logging an object, it shows __proto__ as part of the properties of the object What is the expected behavior? It should highlight the fact that the prototype link is special and not a normal property. It should use a syntax similar to function objects, which already have things like [[FunctionLocation]] and [[Scopes]]. It should should follow the ECMAScript spec convention of denoting internal slots with double brackets. What went wrong? __proto__ is deprecated and should not be used any more in any code (the replacements Object.getPrototypeOf/setPrototypeOf work much better). __proto__ is just an inherited getter/setter, but seeing it in the devtools is very confusing. Especially for new developers, it leads to a misguided understanding, thinking that __proto__ is an own property of every object that will be used for looking up inherited properties. They continue to use it in their own code to access (and sometimes even change) the prototype chain, not being aware that they use a deprecated web-legacy feature. Did this work before? No Chrome version: 64.0.3282.189 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: (I love the change from "undefined" to "empty" for array slots <https://bugs.chromium.org/p/chromium/issues/detail?id=732021> :D)
,
Mar 2 2018
,
Sep 25
,
Oct 4
+Erik for future discussion. It sounds like a reasonable feature request but I would prefer to have some other notation then '[[...]]' since we use it for internal properties which are usually not important.
,
Oct 4
For comparison, Firefox: `<prototype>: {...}`
We also use the `<>` bracket notation for Promises (e.g. `Promise {<pending>}`), and doing the same for prototype sounds fine here, and possibly for `<default properties>` on Window / Elements in the future.
,
Nov 16
Since there is no strong need to change this, we prefer to keep it. Archiving.
,
Dec 17
Aww. Hundreds of confused novice developers disagree that there is no strong need, but I suppose I can't change your decision. |
||||
►
Sign in to add a comment |
||||
Comment 1 by susan.boorgula@chromium.org
, Feb 28 2018