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 :-)
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
