Call me crazy but I can picture a world where you have to explicitly shim
in __proto__ (using Object.setPrototypeOf) if you really need it. Not
anytime soon, sure, but maybe one day. Maybe...


On Wed, May 8, 2013 at 5:05 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Having Object.setPrototypeOf to match Object.getPrototypeOf is nice,
> better for proxies (with necessary changes to them), and polyfillable.
>
> Take my last note as an attitude adjustment, though. So long as __proto__
> endures, its brevity and legacy uses will tend to propagate its use into
> the future.
>
> In that light, pushing everything but the object literal __proto__ special
> form into Annex B still rubs me the wrong way. I'd do both O.p.__proto__
> and the special form in the main spec, or both in Annex B (to make Andreas
> happy ;-). Not split them up.
>
> /be
>
>
> Allen Wirfs-Brock wrote:
>
>> On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote:
>>
>>  On 8 May 2013 17:41, Allen Wirfs-Brock<allen at wirfs-brock.**com<allen at wirfs-brock.com>>
>>>  wrote:
>>>
>>>> On May 8, 2013, at 8:31 AM, Mark Miller wrote:
>>>>
>>>>  What about your triangle argument?
>>>>>
>>>> There is another way:
>>>>
>>>> let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};
>>>>
>>>> Let's keep {__proto__: foo} in the slightly  disrespectable  Annex B
>>>> box.  That keeps it together with O.p.__proto and leaves room for future,
>>>> more elegant object literal syntax extensions if we decided we really need
>>>> them (and we probably won't).
>>>>
>>> Isn't Object.create the proper alternative to both {__proto__: } and
>>> triangle for objects? What has setPrototypeOf got to do with it? (And
>>> why is that on the table all of a sudden?)
>>>
>>
>> I think that Brandon Benvie adequated addressed Object.create.
>>
>> Regarding setPrototypeOf, once Mark agreed that the [[protoSetter]]
>> function did not need to be Realm restricted it essentially became a
>> publicly available API for modify the [[Prototype]] of arbitrary objects.
>>
>>        Object.**getOwnPropertyDescriptor(**Object.prototype,
>> "__proto__").set.call(obj, proto)
>>
>> There is a vocal part of the JS community who would prefer that the core
>> language also offer Object.setPrototypeOf as the preferred alternative to
>> the above:
>>
>>         Object.setPrototypeOf(obj,**proto)
>>
>> This is only a cosmetic difference. But I agree that it is good
>> cosmetics. Dynamic prototype modification seems to have won as a required
>> feature of the language.  Since that is the case, consistancy suggests that
>> we should  treat it cosmetically just like all the dynamic reflection
>> operations defined on Object.
>>
>> Allen
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130508/86332ee0/attachment.html>

Call me crazy but I can picture a world where you have to explicitly shim
in `__proto__` (using `Object.setPrototypeOf`) if you really need it. Not
anytime soon, sure, but maybe one day. Maybe...