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?
> 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>
>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss