Mutable Proto

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 20 23:38:59 PDT 2013


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 <brendan at 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.rick at gmail.com<mailto:
>> waldron.rick at gmail.com**>> wrote:
>>
>>
>>
>>
>>     On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi
>>     <andrea.giammarchi at gmail.com <mailto:andrea.giammarchi@**gmail.com<andrea.giammarchi at 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
>>
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130320/61dd9c62/attachment-0001.html>


More information about the es-discuss mailing list