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
