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

> 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](https://twitter.com/izs) tweeted something you think Node is going to fork V8? Get real!