Any reason why __proto__ is not a well known symbol?

Leo Balter leonardo.balter at gmail.com
Tue Feb 16 19:21:03 UTC 2016


For the sake of consistency and compatibility, instead of the following
example:

`{__proto__:null, key: 'value'}`

Let this key be represented by a `Symbol.proto` or `Symbol.toPrototype`.
This would work fine to avoid using Object.create getting descriptors or
along Object.assign.

unless TC39 want to represent other Symbols within the `__` notation,
`__proto__` should be left alone and die in the first moment it's possible.


On Tue, Feb 16, 2016 at 2:45 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> 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
> 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'}})`
>    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
> behavior.
>
> Just my 2 cents
>
> Best Regards
>
>
>
>
>
> On Tue, Feb 16, 2016 at 4:00 PM, Dean Landolt <dean at deanlandolt.com>
> wrote:
>
>>
>>
>> On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <jackalmage at gmail.com>
>> wrote:
>>
>>> On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <coroutines at gmail.com>
>>> wrote:
>>> > On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <jackalmage at gmail.com>
>>> 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 mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160216/1b319e47/attachment.html>


More information about the es-discuss mailing list