Any reason why __proto__ is not a well known symbol?

Bergi a.d.bergi at web.de
Tue Feb 16 21:00:46 UTC 2016


Andrea Giammarchi wrote:

> As much as Id love to see dunder-`__proto__` burn away from any future
> specification,

Before doing that, we should burn it away from everyones code :-)

> there are at least two use cases I do like in terms of
> simplification:
>
>     1. to shortcut literals with enumerable, configurable, and writable own
>     properties that extend known objects (or null) such `{__proto__:null, key:
>     'value'}` . This cannot be compared with the tedious `Object.create(null,
>     {key: {enumerable: true, writable: true, configurable: true, value:
>     'value'}})`

The much simpler solution to that would be `Object.setPrototypeOf({key: 
'value'}, null)` (which also returns the object). Admittedly, putting 
the prototype in the end is a bit awkward, and `__proto__` in a literal 
probably simplifies creation optimisations.
The way to overcome this would be to promote the [prototype `<|` 
operator](http://wiki.ecmascript.org/doku.php?id=harmony:proto_operator), which 
I would love to see in ES8. Anyone up for making an up-to-date proposal?

>     2. to explain inheritance through the console or to people in general,
>     using it only as virtual-read-only reference to the inheritance chain

I wholeheartedly recommend to use the term *[[prototype]]* (in italics 
or color) for this, and call it out as what it is: an **internal** 
property. Don't teach people that `__proto__` is a magical property - it 
is not (causing confusion); and they only will start or continue using 
it in new code.
Even in code examples, or simple demonstrations, use `console.log(x, 
Object.getPrototypeOf(x))` over `console.log(x, x.__proto__)`.

Regards,
  Bergi

PS: Ceterum censeo __proto__ esse delendum :-)


More information about the es-discuss mailing list