<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Feb 9, 2012, at 7:18 PM, Allen Wirfs-Brock wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div>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.</div></span></blockquote><div><br></div><div>Hi Allen,</div><div><br></div><div>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.</div></div><div><div><br></div><blockquote type="cite">Finally there is the object literal issue which was not address by the original wiki proposal.</blockquote></div><br><div>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.</div><div><br></div><div>cheers,</div><div>G.</div><div><br></div><div><br></div></body></html>