2012/11/14 Allen Wirfs-Brock <[email protected]> > 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. - 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. At its core, this "footgun" is not specific to Javascript proxies: it's an 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 :-) Cheers, Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
