A Precedent

Brendan Eich 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 mailing list