Jan 29 TC39 Meeting Notes

[Claude Pache]

Le 8 févr. 2013 à 23:07, David Bruant <bruant.d at gmail.com> a écrit :

> 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.
The behaviour described in [1] is regular:  {}.__proto__ is equal to Object.prototype.__proto__ by prototypal inheritance, which is a setter that fails silently when fed with a non-object; and Object.create(null) has no prototype, so that setting something to *.__proto__ creates a regular data property. Please blame the ES5 object model, not __proto__. 
> 
>>> 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".
Since BC is not an issue, let's pick the semantic that is most conform to the existing Ecmascript object model, and let's not invent a "weird: true" property descriptor just because we think that __proto__ deserves one. 

> 
>> 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.
The goal is to standardise the least weird thing possible. Indeed, backward-compat doesn't care. 

—Claude

> 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