Le 24/05/2012 20:10, Brendan Eich a écrit :
David Bruant wrote:
Thanks for the notes and complements :-)
Le 24/05/2012 04:43, Brendan Eich a écrit :
Rick Waldron wrote:
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?
Not just array -- DOM too.
DOM is a very interesting case, because the proto operator was not an
option for them since most of them are created by method calls (not even
constructors) and the DOM API is not at all thought to change the
prototype (like JSON.parse).
) cannot be achieved anymore.
So don't delete __proto__ :-P.
Really, you can't have it both ways. If you want Zepto, you are not
running SES code. Let's see if someone can "cajole" Zepto and then talk.
What I was getting at by mentionning Zepto was more about the use case
that led to the decision to use __proto__ rather than Zepto itself.
The use case of subclassing native constructors (just to clarify I'm
only talking about Array, Date, WeakMap, etc. Not DOM constructors) is
legitimate and has been raised and detailed in length [1] (the initial
message does not point that out, but the rest of the thread does). Being
able to *securely* do that is still a use case.
The proto operator was a solution to it but it's out. __proto__ is out
because secure JS code first instruction will be to delete it on go on
as if it never existed. Extracting just a __proto__ setter is not an
option according to what you're saying below. What is there left for the
subclassing use case? So far, I don't see anything.
The aforementioned thread raised 2 interesting alternatives to __proto__
[2] [3] for the subclassing use case. Could it be considered to
standardize any of these functions (or something else as long as it
solves the use case)?
Unlike grawlix, this function will be polyfillable with __proto__ where
it's available. In platform with a native support for this function, it
will be possible to both use this function (solving the use case) and
delete __proto__ (doing it safely).
Does it sounds like a good alternative?
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?
No, we agreed that adds a new hazard not present in almost all
browsers today or over the last 12 years: an extractable setter. We
agreed to spec __proto__ as a magic data property.
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?
There is, just as there's a cost to Object.setPrototypeOf (the obvious
place to put it to match Object.getPrototypeOf from ES5). Mark pointed
out that he'd have to delete that static method too, and from every
frame that might run SES code. But when mashing up SES and non-SES
code, it would be better not to break the non-SES code by such deletion.
Having only the SES environment's Object.prototype.__proto__ to delete
is better.
And I realize that the new hazard is not due to __proto__ in itself, but
rather to the capability of arbitrarily changing the prototype of an
object, so adding an Object.setPrototypeOf really is a step backward.
David
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013131.html
[2] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013141.html
[3] https://mail.mozilla.org/pipermail/es-discuss/2011-March/013154.html
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
