If the extensible proxy has no access to the original
Object.prototype.__proto__, then it cannot modify the [[Prototype]] of its
target, and so should not be able to seem to have its own mutable
[[Prototype]]
On Thu, Oct 4, 2012 at 12:55 PM, David Bruant <bruan...@gmail.com> wrote:
> Le 04/10/2012 20:35, Mark S. Miller a écrit :
>
> On Thu, Oct 4, 2012 at 8:40 AM, David Bruant <bruan...@gmail.com> wrote:
>
>> * It allows the target to be modified first, in anticipation of the
>>> target being queried at the end of the trap.
>>>
>> Do we really need to change the target prototype before reporting a
>> different prototype?
>> IIRC for performance reasons, it's been decided to not perform any
>> inheritance-related invariant check, so which object is in the prototype or
>> reported as such does not really matter since it provides no guarantee for
>> set/get/has traps. For these traps, any lie can be told for not-own
>> properties. In that context, being forced to return a given prototype is a
>> bit too much in my opinion since it's not an information client code can
>> really rely on for anything
>> Things are a bit different for non-extensible objects from which we can
>> have stronger expectations (since setting __proto__ doesn't work for them)
>>
>
> That last is really the point. It enforces that a proxy cannot appear to
> change its __proto__ unless it really can change the __proto__ of its
> target. Besides non-extensibility, another reason it may not be able to is
> that the relevant Object.prototype.__proto__ was deleted and the proxy's
> handler has no access to its original value.
>
> I'm not sure I understand your answer.
> Should the invariant stand even for extensible proxies?
>
> David
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
