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 <[email protected]> wrote:
>
>
> On Tue, Feb 16, 2016 at 1:23 AM, Tab Atkins Jr. <[email protected]>
> wrote:
>
>> On Mon, Feb 15, 2016 at 9:14 PM, Coroutines <[email protected]> wrote:
>> > On Mon, Feb 15, 2016 at 8:51 PM, Tab Atkins Jr. <[email protected]>
>> 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
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
