Any reason why __proto__ is not a well known symbol?
Dean Landolt
dean at deanlandolt.com
Tue Feb 16 16:00:51 UTC 2016
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160216/901b2407/attachment.html>
More information about the es-discuss
mailing list