Le 26/05/2012 22:01, Brendan Eich a écrit :
Domenic Denicola wrote:
Is there a parallel to be drawn with
__(define|lookup)(Getter|Setter)__, or is __proto__ different? I
quite liked Allen's blog post about why IE decided to never support
them [1]. Following that reasoning seems to lead to specifying
Object.setPrototypeOf as a __proto__ replacement,
No. First, you missed Mark's argument that I paraphrased against a
per-frame (window, global context) static method, which David Bruant
acknowledged in this thread just eight messages back:
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
If I understand correctly the SES issues are linked to the capability of
being able to modify the [[prototype]] internal property of an existing
object, that's why it did not surface with the triangle proposal
(because a new object is created)
Then what about something doing : obj = Object.create(proto,obj's
properties) instead of obj.__proto__ = proto or setPrototypeOf ? Where
obj's properties are handled internally
--
jCore
Email : [email protected]
Web : www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
