Jan 29 TC39 Meeting Notes

David Bruant bruant.d at gmail.com
Fri Feb 8 14:07:00 PST 2013


Le 08/02/2013 19:35, Allen Wirfs-Brock a écrit :
> On Feb 8, 2013, at 10:15 AM, Claude Pache wrote:
>> The magic is not in the form of the '__proto__' property of the 
>> Object.prototype object, but in the action that its setter performs.
You're assuming it's a setter already, but that's not a given. Even 
Firefox's recent accessor has some weirdnesses [1], making it 
not-such-an-accessor.

>> Precisely, as implemented in the latest versions of Safari and Firefox (I haven't tested other browsers)
In Chrome and Node, Object.getOwnPropertyDescriptor(Object.prototype, 
'__proto__') is undefined. From that (and the fact that Firefox move to 
a setter is recent), we can conclude that the backward-compat story is 
"no one cares about this detail".

> The "magic" that was being proposed at the meeting was that
>       Object.getOwnPropertyDescriptor(Object.prototype,"__proto__"}
> would return an accessor property descriptor whose "set" property ("and "get"??) was a function like:
>       function () {throw new TypeErrorException}
>
> This violates the mundane inherited accessor property equivalence for situations like:
>       obj.__proto__ = foo;
> and
>        Object.getOwnPropertyDescriptor(Object.prototype,"__proto__").set.call(obj,foo);
>
>
> But such a relationship between [[Get]]  or [[Set]] and [[GetOwnProperty]] has never been identified as an essential invariant and it is easy to create a proxy that does not have that behavior.  So what was proposed is only "magic" from the perspective of ordinary objects.
I'm somewhat surprised any form of consistency with existing 
properties/invariant is discussed at all.
__proto__ is in ES6 as a de-facto standard. What is needed is 
"obj.__proto__ = obj2" to work. To avoid problems, it should be possible 
to delete __proto__, and it'd be preferable to avoid having an 
extractable usable setter (the goal is to de-facto standardize, lipstick 
isn't necessary). *Any* solution in these constraints in acceptable. 
Accessor? data? "magic:true" property? That's all the same. 
Backward-compat doesn't care.
I understand from the notes that the topic had some... emotion to it. 
Toss a 3-sided coin at next TC39 meeting?

David

[1] https://twitter.com/olov/status/298395329945030657


More information about the es-discuss mailing list