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.
Cheers On Sun, Apr 21, 2013 at 8:45 PM, Brendan Eich <[email protected]> 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 < >> [email protected] >> <mailto:andrea.giammarchi@**gmail.com<[email protected]>>> >> wrote: >> >> On Sun, Apr 21, 2013 at 6:11 PM, Allen Wirfs-Brock >> <[email protected] <mailto:[email protected]>**> 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 >> [email protected] <mailto:[email protected]**> >> >> >> 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 >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
