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 <[email protected]
<mailto:[email protected]>> wrote:
On Wed, Mar 20, 2013 at 3:40 PM, Andrea Giammarchi
<[email protected] <mailto:[email protected]>>
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
