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
