How to clean up __proto__ (was: Why we need to clean up __proto__)

Mark S. Miller erights at google.com
Thu Dec 29 11:41:47 PST 2011


Hi Allen, that's very clever. But I don't think it is needed.

David is right about running first. I also don't have a proof, but
practically I'm sure that for JS as it is and will continue to be under
ES-next, unless some trusted code runs in a context (frame) to initialize
itself before any untrusted code runs in that context, all is lost anyway.

So if there's not really anything to be gained by this more complex
normative-optional behavior, I'd rather avoid the extra complexity.


On Thu, Dec 29, 2011 at 8:57 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Dec 29, 2011, at 3:38 AM, Lasse Reichstein wrote:
>
> > There is one side-effect to defining __proto__ using a getter/setter
> > property. You can extract the setter and store it for later, allowing
> > you to change the prototype of objects after someone else deleted the
> > __proto__ property.
>
>
> Not if the built-in setter function for __proto__ is defined similarly to:
>
>     Object.defineProperty(Object.prototype,'__proto__',
>        {set: function __proto__(value) {
>              if (Object.getPropertyDescriptor(this,'__proto__').set !==
> __proto__) throw new TypeError('invalid use of __proto__');
>              ... //do the work of validating and setting [[Prototype]] of
> this
>       }});
>
> (and assuming that Object.getPropertyDescriptor is defined to access
> inherited properties)
>
>
> Allen
>
>


-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111229/b7d4192e/attachment.html>


More information about the es-discuss mailing list