Aymeric Vitte wrote:
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
We covered this already, I think.
The problem remains that __proto__ is out now, all over the "mobile
web". An API requires polyfilling and authors won't do it just to help a
new browser enter that market, and the browser vendor trying to enter
will throw in the towel and implement __proto__ to solve this
chicken-and-egg problem.
An Object.make (nicer Object.create, as you sketch: pass an object
literal by which to extend the proto parameter, instead of a pdmap) is
plausible, but a separate proposal that does not take away one bit of
__proto__'s inertia and momentum.
Allen showed how mustache can be used to make up for lack of <| or
Object.make:
var obj = Object.create(proto).{prop: val, prop2: val2};
It's only slightly longer and it falls out of ES5 + mustache (if we can
agree on mustache).
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
