Le 28/01/2012 18:16, Brendan Eich a écrit : > I don't think we should change __proto__ unnecessarily from current > implementations, including making it an accessor. Neither JSC nor > SpiderMonkey does that. > > We do need the ability to delete it, so it should live on > Object.prototype and be configurable. Having given more thought about it, I agree that making __proto__ a setter is unnecessary and will lead to some additional complication. Benefits are things that are not wanted anyway.
It is unnecessary, because it is currently not a setter everywhere (so if people rely on __proto__, they do not rely in it being an accessor) and if __proto__ was an accessor it would be an encouragement to use the setting part as a capability. If a setter could be extracted, people will write code extracting it and lead to a position from which implementors won't be able to come back, maybe permanently being stuck with a [[Prototype]] setting capability in "JS-of-reaity". Regarding the specification (as optional normative) of __proto__ as an data descriptor, either the spec can invoke some magic (which is what implementations already do from an ES5 point of view) or redefine Object.prototype as a proxy. The target of this proxy would be the standard Object.prototype and the handler would just define some trap behavior that deal with __proto__. David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
