Thanks for the notes and complements :-)
Le 24/05/2012 04:43, Brendan Eich a écrit :
Rick Waldron wrote:
Triangle
Is capable of giving up private names
If people have __proto__ they will not use <|.
I don't know who are "people" but I'm not one of them. <| offered some
nice sugar with regard to constructors. Just sugar but it was convenient.
MM:
- From a security perspective, I'd like to move __proto__ out of
annex B and into normative body
BE:
- If MS puts __proto__ in IE, then it becomes defacto standard and we
might as well put it in the standard.
1. __proto__
2. grawlix
Resolution: Indefinite postpone\
I.e., we defer/cancel triangle and go with normative mandatory
__proto__. W00t! Kidding, mostly, but I perpetrated it, it is in all
browsers but IE, and IE feels the heat on mobile (thank you Thomas
Fuchs!). So __proto__ is the winner already, we're just trying to
forestall the inevitable.
It seems that "delete Object.prototype.__proto__" would be the first
line I'd write if I wanted to prevent __proto__ from being harmful.
However, since <| is out, after doing the delete, the use cases it was
intended for (array subclassing is zepto.js' use case, right?) cannot be
achieved anymore.
I think we can only recover is if it's possible to extract a proto
setter before the delete. I haven't seen a resolution on the
__proto__-related notes, but considering that <| is out, can it be
consider to just do a setter?
Once we're at it, for the sake of completeness there is probably no harm
in adding a Reflect.setPrototype at this point, is there?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
