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>  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
>
>
>
>
>
>
>
>
>

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.