Do we really need the [[HasOwnProperty]] internal method and hasOwn trap
Tom Van Cutsem
tomvc.be at gmail.com
Wed Nov 14 01:25:55 PST 2012
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
- 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.
- 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.
old problem in OO frameworks in general, whose documentation may state: "if
you subclass class C, and you override method "foo", make sure you also
override method "bar" consistently!". I'm sure you've had way more
practical experience with exactly this issue in developing OO frameworks
than I ever have :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss