also, too much power because of a function instead of a hot/swap through a
property ?

who told you nobody wants that function because prefer __proto__ instead ?

Do you read internet where every developer calls __proto__ ugly ?

And btw, which part I did not reply ... I have no idea, honestly!


On Fri, Apr 12, 2013 at 6:27 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> he doesn't need to fork V8, he simply needs to
> delete Object.prototype.__proto__;
>
> at startup time so I am getting real
>
>
> On Fri, Apr 12, 2013 at 6:21 PM, Brendan Eich <brendan at mozilla.com> wrote:
>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130412/06c5b407/attachment-0001.html>

also, too much power because of a function instead of a hot/swap through a property?

who told you nobody wants that function because prefer `__proto__` instead ?

Do you read internet where every developer calls `__proto__ `ugly ?

And btw, which part I did not reply ... I have no idea, honestly!