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 <bren...@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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to