Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
allen at wirfs-brock.com
Wed Nov 14 09:13:21 PST 2012
On Nov 14, 2012, at 1:25 AM, Tom Van Cutsem wrote:
> 2012/11/14 Allen Wirfs-Brock <allen at wirfs-brock.com>
> Regardless, my main concern isn't this optimization issue, but instead a concern about it being too easy to inadvertently define an internally inconsistent Proxy.
> Indeed. So let's get back to alternative solutions to avoid the inconsistent Proxy issue.
> As I mentioned previously, I think knowing about the Handler API, and when to use it, is key:
> - You don't need to subclass Handler if you are building proxy abstractions that only do before/after/around-style wrapping of a target object. Even if you implement only some of the traps and leave the others in "forwarding mode", as even your own traps eventually "forward", the resulting proxy is still consistent.
Yes, a very good point and one that isn't necessary obvious in the present APIs and documentation. I can imagine ways to make this more explicit in the APIs. For example providing for before_has, after_has, etc. entry points in the handler interface or by having an addition WrappingProxy constructor that takes both a before handler and an after handler (and other embellishment to tie them together).
> - You want to subclass Handler if you are building proxies that are either not backed by a wrapped target object, or you do want to wrap an object but do not want to forward all operations to it. At that point, you want to make sure that no trap lingers accidentally in the "forwarding" state. The Handler API (with abstract fundamental traps) ensures this.
Can we ensure that programmer do this. Perhaps by requiring that all handler objects are branded as such. This would most directly be accomplished via inheriting the brand.
> - We don't want meta-programmers to have to know the intricate details of the default trap implementations. Instead, all a meta-programmer subclassing Handler should care about are the dependencies between fundamental and derived traps, i.e. "for each derived trap, what fundamentals must I provide?". At this point we don't yet have good docs that document this relationship.
More generally stated, what are the invariants and post-conditions of each abstract trap.
Yup, this is a fine example of why it is important to carefully distinguish the external client contract (in this case, what a client can expect from each trap call) and the subclass/extension contract (how the implementation of the traps are factored and interdependent and which invariants must be maintained when extending the implementation).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss