Dean Landolt wrote:
> 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...

Who can say? It's fruitless to speculate idly. Want to bet?

But aside from wagers, in the foreseeable future, we need to spec 
__proto__ somewhere.

/be
>
>
> On Wed, May 8, 2013 at 5:05 PM, Brendan Eich <brendan at mozilla.com 
> <mailto: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
>             <mailto: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 <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>

Dean Landolt wrote:
> 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...

Who can say? It's fruitless to speculate idly. Want to bet?

But aside from wagers, in the foreseeable future, we need to spec 
`__proto__` somewhere.