B.3.1 The __proto__ pseudo property

Brendan Eich brendan at mozilla.com
Sun Apr 21 20:45:06 PDT 2013

Andrea may be asking for less than the standard someday removing 
__proto__, if I read him right. He's asking not to keep it 
"indestructible", i.e., to make

   delete Object.prototype.__proto__

remove all the magic, including for 'o = {__proto__: p}'.

But that seems to require using [[Put]] rather than [[SetInheritance]], 
and you said that's a security problem. Could you show how? I asked in 
my immediately preceding message how creating custom proto-chains for 
guaranteed fresh objects via literals makes trouble for SES.


Mark Miller wrote:
> Hi Andrea, Allen's immediately previous sentence was
> "The point is that I don't think there is any long standing behavior 
> in this regard relating to object literals and deleting 
> Object.prototype.__proto__ that the web is dependent upon."
> This sets the context for understanding Allen's next sentence. We are 
> constrained by cross-browser legacy. So long as IE was not planning to 
> implement __proto__, we avoided standardizing it. In the current 
> situation, TC39 is powerless to prevent __proto__ becoming a 
> cross-browser standard. Our only choices are
> 1) We design and codify a spec that all these browsers can agree on, 
> that does not break existing cross-browser (IE aside) web content, and 
> that is as clean as possible *within* those constraints.
> 2) We do not do so, in which case each browser gropes separately to be 
> compatible enough with what the other browsers seem to be doing.
> And example of the consequences of #2 is the wildly different and 
> often bizarre semantics of block nested functions. This was the 
> consequence of omitting these from "official" JavaScript in a 
> social/political context where all browsers felt compelled to 
> implement them anyway. They groped towards compatibility without 
> coordination and arrived at painfully incoherent 
> results. (Fortunately, we were able to quarantine this bizarreness to 
> sloppy mode.)
> As a standards committee, we need to be realistic about when we can 
> exercise normative power and when we can't. I'll even agree that, when 
> we're uncertain, we should err on the side of cleaning things up. 
> Until IE changed expectation, we were doing exactly that by avoiding 
> __proto__. Today, we no longer have that happy uncertainty.
> On Sun, Apr 21, 2013 at 6:47 PM, Andrea Giammarchi 
> <andrea.giammarchi at gmail.com <mailto:andrea.giammarchi at gmail.com>> wrote:
>     On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock
>     <allen at wirfs-brock.com <mailto:allen at wirfs-brock.com>> wrote:
>         We are free to specify a semantics that will make sense, now
>         and for the long term.
>     then, for the long term, if all I understood about this thing is
>     that stinks for everybody, you should really consider to give
>     developers the possibility to get rid of this property completely,
>     if desired, instead of making it indestructible, IMHO
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
> -- 
> Text by me above is hereby placed in the public domain
>   Cheers,
>   --MarkM

More information about the es-discuss mailing list