New ES6 draft now available

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Nov 27 22:13:31 PST 2012


On Nov 27, 2012, at 6:19 AM, Tom Van Cutsem wrote:

> 
> 
> 2012/11/26 Allen Wirfs-Brock <allen at wirfs-brock.com>
> 
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121127/a344bfb5/attachment.html>


More information about the es-discuss mailing list