We don't currently have the concept of an object "belonging" to a realm.  Functions have a realm association, but not non-function object.

Object.create(parent);    //we have no way to determine if parent "belongs" to the same realm as Object.create.
we also currently have no way to determine whether the caller of  Object.create is in the same or different realm as Object.create.

someObject.__proto__  = someParent;  //the setter function from Object.prototype has no way to determine a realm association for someParent.

let protoSetter = Object.getOwnPropertyDescriptor(Object.prototype, "__proto__");  //a proto setter from some realm

let x = {};
protosetter.call(x, another);    //no realm info to validate.

protosetter is essentially a universal setPrototypeOf function.

The only way I see to tame any aspect (for example not allowing Object.prototype.__proto__ = something) of __proto__ setting is via a [[Set]] over-ride on Object.prototype.

Allen



On Apr 22, 2013, at 7:29 AM, Andreas Rossberg wrote:

> On 22 April 2013 15:49, Brendan Eich <brendan at mozilla.com> wrote:
>>> However, in that case, I actually think that there is no need to have
>>> any special poisoning semantics when reflecting __proto__ -- mainly
>>> because the cross-realm check is already necessary in the unreflected
>>> case: you can construct an object o in realm A with an
>>> Object.prototype from another realm B on its proto chain. If you
>>> deleted __proto__ on realm's A Object.prototype, I don't think it
>>> should still be possible to assign to o.__proto__, should it?
>> 
>> Why not, if in realm A we evaluate 'var o =
>> Object.create(B.Object.prototype)'? You specified 'delete
>> A.Object.prototype' happened, and A.Object.prototype is not on o's proto
>> chain.
> 
> My understanding of the motivation for poisoning was to enable the
> deletion of O.p.__proto__ when configuring a realm as a means for
> guaranteeing that no object from that realm can ever have its
> prototype mutated. Allowing the above case would seem to shoot a hole
> into that.
> 
>  // Realm A
>  delete Object.prototype.__proto__  // no messing around
> 
>  let other = getObjectFromSomewherePotentiallyAnotherRealmB()
> 
>  let p1 = Object.create(other, {a: {value: 1}})
>  let o = Object.create(p1)
>  let p2 = Object.create({})
>  o.__proto__ = p2  // say what?
> 
> 
>>> Whether a
>>> difference should be made between quoted and unquoted I don't know, I
>>> must have missed the rationale for such a move.
>> 
>> I think we're not going to induce vomiting by making a quoted vs. unquoted
>> distinction, in light of Mark's point about computed property names.
> 
> OK, good. :)
> 
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>

We don't currently have the concept of an object "belonging" to a realm.  Functions have a realm association, but not non-function object.

```js
Object.create(parent);    //we have no way to determine if parent "belongs" to the same realm as Object.create.
```

we also currently have no way to determine whether the caller of `Object.create` is in the same or different realm as `Object.create`.

```js
someObject.__proto__  = someParent;  //the setter function from Object.prototype has no way to determine a realm association for someParent.

let protoSetter = Object.getOwnPropertyDescriptor(Object.prototype, "__proto__");  //a proto setter from some realm

let x = {};
protosetter.call(x, another);    //no realm info to validate.
```

`protosetter` is essentially a universal `setPrototypeOf` function.

The only way I see to tame any aspect (for example not allowing `Object.prototype.__proto__ = something`) of `__proto__` setting is via a [[Set]] over-ride on `Object.prototype`.