On Nov 27, 2012, at 6:19 AM, Tom Van Cutsem wrote: > > > 2012/11/26 Allen Wirfs-Brock <[email protected]> > > On Nov 26, 2012, at 10:56 AM, Tom Van Cutsem wrote: > >> I'm skeptical though, whether this change achieves your original goal of >> reducing the risk of inconsistencies between the different operations. It >> depends on whether you think doing a case-analysis using switch or if-tests >> is less error-prone than having to override/implement multiple different >> traps. > > Yes, I do think case analysis in a single function is less error-prone. I > think logic that is centralized to a single function is more likely to > self-consistent than logic that has to be duplicated in multiple functions. > Particularly, when it is possible to redefine the multiple functions > individually without being forced to redefine the entire set. > > It's all a matter of trade-offs. One thing that we lose by bundling > everything into a single trap is the ability to easily add new traps with > default semantics. One of the reasons for baking the Handler API into the > spec was that we could add new derived traps in ES7+, and Proxy abstractions > whose handler subclasses Handler would inherit a sensible default > implementation of these new derived traps. > > When dealing with a getIntegrity/setIntegrity trap, it's not easy to add a > new object state later: the existing case-analysis code won't be prepared to > deal with it.
The basic argument would seem to apply to any relatively complex trap/internal method semantics. For example, if we added a new attribute to property descriptors or and enhanced semantics for property get/put (for example, comparable to the changes that we necessarily to originally add accessor properties). In this particular case, a well designed setIntegrity trap handler should probably just forward any unrecognized states on to Reflect.setIntegrity(target,state) We making trade-off across several dimensions: size of the MOP, ease of extensions, minimizing chance of inconsistencies, etc. It feels to me like setIntegrity would be a net positive improvement, but that is certainly open to debate. Allen > > Cheers, > Tom
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
