- From: <bugzilla@jessica.w3.org>
- Date: Sat, 05 Mar 2011 17:19:48 +0000
- To: public-script-coord@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12248 --- Comment #4 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2011-03-05 17:19:47 UTC --- (In reply to comment #3) > Brendan, as long as evaluation order is defined, and as long as all DOM APIs > that take such objects specify exactly what happens in "evil" getter cases > (closes window, spins event loop, reenters this API, whatever), it's fine. But > that's a pretty noticeable specification and implementation burden... As Brendan alluded to in Comment 2, the trick is to perform all [[Get]] accesses and cache values of the properties of concern prior to starting the core semantic processing of the API routine. Any side-effects that may occur cannot interact with the API implementation because it hasn't started yet. It is essentially as if the caller had done the accesses prior to the call and passed the retrieved values. When done in this manner the access order really should make many any difference to the implementation of the API functionality. However, for maximal interoperability you probably what to specify it as well as any coercions that are done on the retrieved values. That's how we do it in the ES5 spec. The specification burden seems minor in appropriate boiler plate language is defined: "Let a,b,c,x,y,z be the values of the like-named properties of obj." If you are using some sort of "typed" description of the expected properties the coercions can be implicit. Concerning implementation burden. All ECMAScript built-in already have to worry about such things. I don't see how web-app API can avoid it. The burden isn't excessive, it is an inherent tax for supporting a dynamically typed language. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Saturday, 5 March 2011 17:19:49 UTC