Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
allen at wirfs-brock.com
Mon Nov 12 14:09:45 PST 2012
On Nov 12, 2012, at 1:00 PM, Tom Van Cutsem wrote:
> 2012/11/12 Allen Wirfs-Brock <allen at wirfs-brock.com>
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss