brendan at mozilla.com
Fri Apr 12 18:21:05 PDT 2013
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!
More information about the es-discuss