New ES6 draft now available

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Nov 26 13:09:31 PST 2012


On Nov 26, 2012, at 10:56 AM, Tom Van Cutsem wrote:

> 2012/11/26 Allen Wirfs-Brock <allen at wirfs-brock.com>
> 
> On Nov 26, 2012, at 9:44 AM, Tom Van Cutsem wrote:
>> W.r.t. freeze and friends, I thought you were considering a more generic [[GetIntegrity]]/[[SetIntegrity]] operation.
> 
> Yes, are you on board with that?
> 
> Yes, I haven't yet considered all the implications, but it seems fine.
> 
> The initial discussion was about the usefulness of being able to trap freeze/isFrozen. I argued that having these traps allows proxies to more efficiently implement those operations (the alternative being to call defineProperty/getOwnPropertyDescriptor on each individual property).
> 
> Having [[GetIntegrity]]()//[[SetIntegrity]](State) (with corresponding traps) retains the ability for proxies to efficiently change their state to frozen, or return an answer to an integrity query. It also makes the internal states of an object more explicit in the specification, which is good.
> 
> 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.

Allen

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


More information about the es-discuss mailing list