On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <nathan.wall at live.com> wrote:

> >> Do you think we can come to some sort of agreement, as discussed below,
> >> that [[ProtoSetter]] doesn't need to be realm restricted. Such an
> >> agreement would let us write the simplest possible specification of
> >> __proto__.
> >
> > Very timely question. I've discussed this within the other Cajadores
> > and the answer is yes. While the range restriction help security in
> > some ways, it doesn't help a lot, and it actually hurts in other
> > ways. Such simplicity itself is of benefit to security, and weighs in
> > the overall tradeoff. On balance we're better off without it. I'll be
> > posting publicly on this soon.
>
> ...
>
> >> It would also remove all obstacles to having Object.setPrototypeOf
> >> which a number of vocal community members would really prefer to have
> >> built-in and available rather than having to use __proto__ ugliness.
> >
> > Yes. All objections to this disappear. And likewise for having proxies
> > handle trapping proto changes differently from their handling of other
> > changes.
>
>
> If I didn't misinterpret, this sounds like a very, very a welcome
> discussion -- one for which I would like to restate that I have a real
> use-case which is not 100% solvable with realm-confined __proto__[1].
>
> I would like to add that, should `setPrototypeOf`, be admitted, it should
> work on objects which don't inherit from `Object.prototype` in order to
> settle my use-case (and also from a purist's point of view of how the
> language should behave). If `setPrototypeOf` is not admitted, I would hope
> that at least __proto__ will be a setter which can be retrieved with
> `getOwnPropertyDescriptor` and applied to objects which don't inherit from
> `Object.prototype`.
>

Agreed on both. The only restriction we need is the one that ES5 already
gives us: You can't change the [[Prototype]] of a non-extensible object.



>
> Please keep up the discussions around this issue!
>
>
>
> [1] https://mail.mozilla.org/pipermail/es-discuss/2013-March/029329.html
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130507/322df654/attachment.html>

On Tue, May 7, 2013 at 11:09 AM, Nathan Wall <nathan.wall at live.com> wrote:

> If I didn't misinterpret, this sounds like a very, very a welcome
> discussion -- one for which I would like to restate that I have a real
> use-case which is not 100% solvable with realm-confined `__proto__` [1].
>
> I would like to add that, should `setPrototypeOf`, be admitted, it should
> work on objects which don't inherit from `Object.prototype` in order to
> settle my use-case (and also from a purist's point of view of how the
> language should behave). If `setPrototypeOf` is not admitted, I would hope
> that at least `__proto__` will be a setter which can be retrieved with
> `getOwnPropertyDescriptor` and applied to objects which don't inherit from
> `Object.prototype`.
>

Agreed on both. The only restriction we need is the one that ES5 already
gives us: You can't change the [[Prototype]] of a non-extensible object.