Mutable Proto

Andrea Giammarchi andrea.giammarchi at gmail.com
Wed Mar 20 14:00:16 PDT 2013


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>wrote:

>
>
>
> On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi <
> 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
>
>
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130320/46d5f340/attachment-0001.html>


More information about the es-discuss mailing list