yes, SES, the non real world out there, needs __proto__ ... shenanigans all over the world because of '__proto__' ain't important.
Thanks to be clear on it On Wed, Mar 20, 2013 at 10:18 PM, Brendan Eich <bren...@mozilla.com> wrote: > Your writing is unclear and overlong, and full of unjustified airs of > grievance -- please work on it. > > To recap yet again (last time): __proto__ is a de-facto standard we cannot > defeat, whether anyone likes it or not. Adding Object.setPrototypeOf does > not help, because code won't migrate to it completely so we'll be stuck > with two APIs. > > If against all odds, all code everywhere *did* magically drop __proto__ in > favor of Object.setPrototypeOf, then SES and similar subsets would be > unable to protect secure code from ambient Object.setPrototypeOf usage from > the insecure side on the secure side's objects, unless > Object.setPrototypeOf were removed -- but that would break insecure-side > code that reasonably (per your wishes) uses Object.setPrototypeOf in lieu > of __proto__. > > Now do you understand? > > /be > > Andrea Giammarchi wrote: > >> never cared about IE much on mobile and I do not care about 100% or >> __proto__ support ... there is 100% of Object.prototype pollution support >> since ever and everybody knows that is a bad technique, specially done >> through direct property rather than through a descriptor. >> >> What is the point then ? Should I feel free to shoot in my foot and in >> all libraries foot because I can change even Object.prototype.__proto__ ? I >> don't think so and I don't understand what is anyone point here. >> >> TC39 decided to do not even talk about __proto__ now is the best thing >> ever to suggest and use because supported ... is not standard and loads of >> shenanigans, is an undesired property full of undesired behaviors ... and >> still you all are protecting it for which reason, exactly? Either you make >> it standard, or you get rid of it ASAP allowing developers that use it >> already to migrate, gracefully, through Object.setPrototypeOf ... and >> considering setPrototypeOf, hidePrototypeOf, and freezePrototypeOf method >> in ES7 ... how does that sound? >> >> 'cause otherwise we can just stop reading specs, if non standard stuff is >> sacre more than specs and standards or potential, better, solutions. >> >> Best Regards >> >> >> >> >> >> On Wed, Mar 20, 2013 at 1:33 PM, Rick Waldron <waldron.r...@gmail.com<mailto: >> waldron.r...@gmail.com**>> wrote: >> >> >> >> >> On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi >> <andrea.giammar...@gmail.com >> <mailto:andrea.giammarchi@**gmail.com<andrea.giammar...@gmail.com> >> >> >> >> wrote: >> >> I think zepto is using that to modify runtime NodeList results >> after querySelectorAll but in any case it was not me saying >> that __proto__ is used already. I use it only to shim >> getPrototypeOf to be honest and I don't think is a good idea >> to use it at all. >> >> My point is that Object.setPrototypeOf does not need a >> property loads of shenanigans as __proto__ is so that no >> Object.prototype.__proto__ would ever exist anywhere. >> >> I don't even know why that existed in first place,to be honest >> ... so do not use it, pass through Object.setPrototypeOf, same >> as you would suggest pass through Object.defineProperty >> instead of using Object.prototype.__**defineGetter__ >> __defineSetters__, both "de facto standards" some time ago. >> >> >> IE never implemented the __defineGetter__ __defineSetter__ but >> they did implement the ES5 Object meta APIs and _are_ implementing >> __proto__ for parity with browsers that currently support it—this >> is the big difference. This is in addition to the rationale >> recorded here >> https://github.com/rwldrn/**tc39-notes/blob/master/es6/** >> 2013-01/jan-29.md#45-why-**standardizing-on-__proto__-** >> and-not-__definegsetter__-__**lookupgsetter__<https://github.com/rwldrn/tc39-notes/blob/master/es6/2013-01/jan-29.md#45-why-standardizing-on-__proto__-and-not-__definegsetter__-__lookupgsetter__> >> >> Rick >> >> >> >> >> >>
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
