Any reason why __proto__ is not a well known symbol?

Andrea Giammarchi andrea.giammarchi at
Tue Feb 16 16:45:08 UTC 2016

As much as Id love to see dunder-`__proto__` burn away from any future
specification, there are at least two use cases I do like in terms of

   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:
   2. to explain inheritance through the console or to people in general,
   using it only as virtual-read-only reference to the inheritance chain

While the first point will be simplified a lot thanks to
`Object.getOwnPropertyDescriptors` so that the literal form can be still
used via `Object.create(null, Object.getOwnPropertyDescriptors({key:
'value'}))` the second point is still interesting but, like I've mentioned,
usable as abstract concept too that doesn't need to be specd' as magic

Just my 2 cents

Best Regards

On Tue, Feb 16, 2016 at 4:00 PM, Dean Landolt <dean at> wrote:

> On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <jackalmage at>
> wrote:
>> On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <coroutines at> wrote:
>> > On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <jackalmage at>
>> wrote:
>> >> It was specified before symbols existed, and all implementations do it
>> >> as a string property.  If we were reinventing it today it would either
>> >> be a symbol or something in the MOP, but are hands are tied by legacy.
>> >>
>> >>> Being that it was not formally spec'd it shouldn't have broke
>> backwards
>> >>> compatibility either.
>> >>
>> >> Backwards compat has nothing to do with specs, and everything to do
>> >> with existing implementations.  Multiple implementations agreed on
>> >> __proto__, so our choice was either to leave it unstandardized or spec
>> >> what the browsers did.
>> >
>> > Is there a migration to make it a Symbol in ES7?  (ignorant question?)
>> There's a lot of code in the wild that uses __proto__ and depends on
>> it.  We can't remove it until/unless that changes (it won't, at least
>> not in the near future), and while we have __proto__, there's no
>> reason to have anything else.
> Is it too late to remove support for dunder-__proto__ strictly within
> module contexts? This might introduce a bit of a refactor hazard when
> pulling old code into modules, but it's only the static `obj.__proto__`
> usage that has any effect so this can be handled pretty easily with linter
> warnings. Or it could be contextually reserved and throw an early exception.
> _______________________________________________
> es-discuss mailing list
> es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list