Hi, I'm also in favor of exposing __proto__ as an accessor on the grounds that it is least magical. I'm worried that the changes made here to the core internal methods [[Get]], [[Put]], [[DefineOwnProperty]] and [[Delete]] will give proxies a hard time to properly emulate this behavior if they would want to do that. How would a proxy handler be able to access the internal variable UnderscoreProtoEnabled?
(I currently assume that in any event, aProxy.__proto__ would just trigger the "get" trap for "__proto__" and that all of this magical behavior does not apply to proxies, only built-in normal objects.) Also +1 to Gavin's proposed alternative to the frame-check. Cheers, Tom 2012/2/10 Gavin Barraclough <[email protected]> > On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote: > > I would expect Gavin's approach to ultimately be even worse than mine from > a semantic analysis perspective. It expose (via > Object.getOwnPropertyDescriptor) functions that have the ability to mutate > any object's [[Prototype]] property and one those functions are exposed > they can be installed as methods or explicitly called at any time. I think > that tame them is likely to have even greater impact than what I have done. > Certainly, for the ES5 language level (which is what my current spec. > addresses) there is no way to talk about frames or the association of one > of these functions or any other object with a frame. With my approach > there is no need to match the proto mutator function's frame with the > target object's frame, because there is no mutator function. > > > Hi Allen, > > I completely agree with you that frame-based checks should not be a part > of the solution, however they are no more necessary if __proto__ is an > accessor property then if it is a data descriptor. The solution I proposed > was that the [[ProtoSetter]] should hold a private reference to the Object > Prototype upon which it is initially assigned, and that upon being invoked > it should walk the this object's prototype chain to see if it any entry > matches the stored value. With a check such as this in place (I expect > there are other ways we could achieve this), it would not be possible to > apply a given [[ProtoSetter]] to any object other than those upon which it > would initially have been available to operate via the Object Prototype. > > Finally there is the object literal issue which was not address by the > original wiki proposal. > > > You're right, we do need to expand the proposal to cover this. This > doesn't seem too difficult. If the identifier being assigned to in an > object literal initialization is "__proto__", then check whether the Object > Prototype contains a property named "__proto__" whose descriptor has a > "set" value equal to that Object Prototype's original [[ProtoSetter]] > function, if so then the assignment sets the newly constructed object's > prototype, otherwise it defines a own property as usual. > > cheers, > G. > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
