Mutable Proto

Brendan Eich brendan at mozilla.com
Wed Mar 20 22:18:18 PDT 2013


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 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__
>
>     Rick
>
>
>
>
>


More information about the es-discuss mailing list