On Nov 12, 2012, at 1:00 PM, Tom Van Cutsem wrote:
> 2012/11/12 Allen Wirfs-Brock <[email protected]>
>
> ...
>
> 2) can be solved by having the handler subclass the standard Handler (see
> <http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api>): by
> "subclassing" the Handler and overriding some fundamental traps, one is
> guaranteed that any derived traps will automatically call the overridden
> fundamental trap.
>
> What we have is a situation that is very similar to that which requires the
> inclusion of a receiver argument in [[GetP]]/[[SetP]] calls, but along a
> different dimension.
>
> I don't yet see how the "receiver" argument is similar to fusing derived and
> fundamental traps into a single trap.
the similarity I meant was between the delegation along the [[Prototype]] chain
and delegation along the [[Target]] chain.
For inheritance we need (for some operations) to know both the object from
which we retrieved the method and the original this object (ie, self vs super
binding) and we deal with it by passing an explicit receiver argument. What is
showing up here is that an analogous situation occurs for [[Target]] delegation
and we haven't accounted for that in the design.
I believe things work out better with the standard Handler because it users the
inheritance dimension to eliminate [[Target]] chain delegation.
>
>>
>> Note that the "invariant enforcement" technique still doesn't allow a proxy
>> with non-config/non-extensibility invariants to lie about its own
>> properties. There are post-condition assertions on both
>> "getOwnPropertyDescriptor" and "hasOwn" that ensure this. More generally: as
>> long as a proxy p doesn't answer "true" to Object.isFrozen(p), its behavior
>> can be arbitrary. Only when some sensible invariants are established on the
>> proxy's target is the proxy's behavior restrained.
>
> Yes, and the concern is that most Proxy uses will not be in the context of
> frozen object so in most cases none of the "invariant enforcement" will not
> help with this problem.
>
> I may have been misunderstood: I didn't claim that invariant enforcement
> solves the forwarding-footgun, only that the inconsistent behavior caused by
> the forwarding-footgun is not in itself an issue. It doesn't invalidate code
> that relies on invariants.
>
> I've never been a big fan of dynamic invariant enforcement for proxies and
> I'm still not. I am concerned that the current interfaces and factoring of
> derived/fundamental along with the target forwarding semantics is a footgun
> that is going to led to difficult to identify bugs.
>
> Hold on: the invariant enforcement mechanism to me feels entirely independent
> of the derived/fundamental trap distinction. We still need invariant
> enforcement even if we fuse all derived traps into the fundamentals (or get
> rid of the derived traps entirely).
>
I agree they are independent mechanisms. I just meant that I didn't think that
trying to added dynamic enforcement of derived/fundamental consistency was an
interesting path.
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
