B.3.1 The __proto__ pseudo property

Andrea Giammarchi andrea.giammarchi at gmail.com
Sun Apr 21 21:42:32 PDT 2013

yep, I was asking to make it neutral 100% but that specific case, as
written many replies before not only by me, seems to be reasonable, as long
as delete Object.prototype.__proto__ is possible and, if this is possible,
hoping that Object.getOwnPropertyDescriptor(Object.prototype,
'__proto__').set will be reusable instead of poisoned.


On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich <brendan at mozilla.com> wrote:

> 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.
> /be
> 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@**gmail.com<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<https://mail.mozilla.org/listinfo/es-discuss>
>> --
>> Text by me above is hereby placed in the public domain
>>   Cheers,
>>   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130421/ac1f1b6d/attachment-0001.html>

More information about the es-discuss mailing list