Dean Landolt wrote:
Call me crazy but I can picture a world where you have to explicitly
shim in __proto__ (using Object.setPrototypeOf) if you really need it.
Not anytime soon, sure, but maybe one day. Maybe...
Who can say? It's fruitless to speculate idly. Want to bet?
But aside from wagers, in the foreseeable future, we need to spec
__proto__ somewhere.
/be
On Wed, May 8, 2013 at 5:05 PM, Brendan Eich <[email protected]
<mailto:[email protected]>> wrote:
Having Object.setPrototypeOf to match Object.getPrototypeOf is
nice, better for proxies (with necessary changes to them), and
polyfillable.
Take my last note as an attitude adjustment, though. So long as
__proto__ endures, its brevity and legacy uses will tend to
propagate its use into the future.
In that light, pushing everything but the object literal __proto__
special form into Annex B still rubs me the wrong way. I'd do both
O.p.__proto__ and the special form in the main spec, or both in
Annex B (to make Andreas happy ;-). Not split them up.
/be
Allen Wirfs-Brock wrote:
On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote:
On 8 May 2013 17:41, Allen
Wirfs-Brock<[email protected]
<mailto:[email protected]>> wrote:
On May 8, 2013, at 8:31 AM, Mark Miller wrote:
What about your triangle argument?
There is another way:
let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
Let's keep {__proto__: foo} in the slightly
disrespectable Annex B box. That keeps it together
with O.p.__proto and leaves room for future, more
elegant object literal syntax extensions if we decided
we really need them (and we probably won't).
Isn't Object.create the proper alternative to both
{__proto__: } and
triangle for objects? What has setPrototypeOf got to do
with it? (And
why is that on the table all of a sudden?)
I think that Brandon Benvie adequated addressed Object.create.
Regarding setPrototypeOf, once Mark agreed that the
[[protoSetter]] function did not need to be Realm restricted
it essentially became a publicly available API for modify the
[[Prototype]] of arbitrary objects.
Object.getOwnPropertyDescriptor(Object.prototype,
"__proto__").set.call(obj, proto)
There is a vocal part of the JS community who would prefer
that the core language also offer Object.setPrototypeOf as the
preferred alternative to the above:
Object.setPrototypeOf(obj,proto)
This is only a cosmetic difference. But I agree that it is
good cosmetics. Dynamic prototype modification seems to have
won as a required feature of the language. Since that is the
case, consistancy suggests that we should treat it
cosmetically just like all the dynamic reflection operations
defined on Object.
Allen
_______________________________________________
es-discuss mailing list
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
