if you consider Object.setPrototypeOf an API and __proto__ another one then
I consider all variants of __proto__ other APIs

As you said we cannot get rid of so standardizing an extra one on top will
create 5 different scenarios.

Old __proto__ will go away, same could be for __proto__ if ES6 will propose
only 1 API, Object.setPrototypeOf, which is new and then surely more
consistent than any other version of __proto__ 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.


On Fri, Apr 12, 2013 at 4:05 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Andrea Giammarchi wrote:
>
>> >  Adding Object.setPrototypeOf does not help, because code won't migrate
>> to it
>> >  completely so we'll be stuck with two APIs.
>> As shown in the first post we'll be stuck with 4 APIs plus the 5th one
>> standardized.
>>
>
> What 4 APIs are you talking about?
>
>
>  The __proto__ that is not supported, the one that is wrongly inherited in
>> Object.create(null), the non configurable, and the configurable without
>> get/set
>>
>
> The old ones go away. We can't fix browsers in the field, you know that.
> Your argument is unfairly lumping changes we *can* make with ones we can't
> and counting them all against the ones we can make.
>
>
>  >  SES and similar subsets would be
>> >  unable to protect secure code from ambient Object.setPrototypeOf usage
>> >  from the insecure side on the secure side's objects, unless
>> >  Object.setPrototypeOf were removed -- but that would break
>> insecure-side
>> >  code that reasonably (per your wishes) uses Object.setPrototypeOf in
>> >  lieu of __proto__.
>> same way SES can protect from __proto__ it can protect from
>> Object.setPrototypeOf redefining in a way that who's white listed can
>> obtain same result.
>>
>
> No, same-frame mashups of SES and non-SES-that-uses-Object.**setPrototypeOf
> cannot "whitelist" unless every SES object (or alternatively non-SES
> object) is put in a whitelist weak-set.
>
> /be
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130412/0714365e/attachment.html>

if you consider `Object.setPrototypeOf` an API and `__proto__` another one then
I consider all variants of `__proto__` other APIs

As you said we cannot get rid of so standardizing an extra one on top will
create 5 different scenarios.

Old `__proto__` will go away, same could be for `__proto__` if ES6 will propose
only 1 API, `Object.setPrototypeOf`, which is new and then surely more
consistent than any other version of `__proto__` 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.