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>wrote: > > > > On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi < > 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__ > > Rick > > > >> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
