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...
On Wed, May 8, 2013 at 5:05 PM, Brendan Eich <bren...@mozilla.com> 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<allen@wirfs-brock.**com<al...@wirfs-brock.com>> >>> 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 > es-discuss@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss