<br><br><div class="gmail_quote">2012/11/26 Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Nov 26, 2012, at 10:56 AM, Tom Van Cutsem wrote:</div><br><blockquote type="cite"><div class="gmail_quote"><div>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.</div>

</div></blockquote><br></div></div></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Cheers,</div>
<div>Tom</div></div>