he doesn't need to fork V8, he simply needs to delete Object.prototype.__proto__;
at startup time so I am getting real On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eich <[email protected]> wrote: > Andrea Giammarchi wrote: > >> if you consider Object.setPrototypeOf an API and __proto__ another one >> then I consider all variants of __proto__ other APIs >> > > As *I* just wrote, this counting old pre-ES6 __proto__ variations is > unfair because ES6 can't affect browsers in the field. Knock it off. > > > As you said we cannot get rid of so standardizing an extra one on top >> will create 5 different scenarios. >> > > Old browsers die off. Stop evading my point. If you can't respond to it, > then stop responding. > > > Old __proto__ will go away, same could be for __proto__ if ES6 will >> propose only 1 API, >> > > No, because your hair-splitting over variations in old __proto__ semantics > does not alter the fact that __proto__ works so well that Microsoft needs > to support it to gain market share. > > Hair-splitting about variations to inflate your count and make an added, > _de novo_ API that no one wants, which is an ambient capability on Object, > is bad and it won't happen. > > > Object.setPrototypeOf, which is new and then surely more consistent than >> any other version of __proto__ >> > > No, it's misplaced and represents too much power in one place. The > SES/non-SES mashup is just one example of this. > > > even with older browsers that supports __proto__ as non configurable and >> inherited in Object.create(null) . >> >> Bear in mind the only reason I am here again is that node.js might decide >> to drop __proto__ and without an alternative the server could miss a handy >> opportunity, for whoever needs it, to promote inheritance in existent >> objects. >> > > Because @izs tweeted something you think Node is going to fork V8? Get > real! > > /be > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
