- From: Dan Evans <devans@invores.com>
- Date: Mon, 07 Jun 2010 16:08:07 -0400
- To: www-voice@w3.org
Chris, As I said, your desire for efficiency is laudable. The sad fact is that, as you point out, the transformation you make for efficiency reasons changes the semantics of the document (as compared to line-by-line interpretation), due to the unfortunate way ECMAScript defines the "var" statement. In line-by-line, the var statement is never executed and thus the variable is never declared. In the "efficient" transformation, ECMAScript will declare the variable even though the code branch containing the "var" statement is never executed. I think the test should be changed, allowing the "efficient" transformation to pass, but if this idea is rejected, the CCXML CR should state that "line-by-line" interpretation semantics must be followed so that further confusion is avoided. If the idea is accepted, the CCXML CR should make some other statement to indicate that such "efficient" transformations are acceptable but that var declarations at points other than the beginnings of scopes can be problematic. Dan On 6/7/2010 12:26 PM, Chris Davis wrote: > Everyone, > > I'm seeking clarification for why this is "reject". I discussed this > w/Dan Evans and he agrees that the test > needs to be changed because as written it requires an inefficient ECMA > embed model to be used. To > quote Dan: > > "After some more study of JS 1.5 and 1.8, some more reading of ECMA-262, > and a lot of examples, I managed to correct my misunderstanding of the > handling of 'var' statements. A 'var' statement, not inside a function, > anywhere in a compilation unit, results in a property definition on the > current scope object when the execution context is created (value > undefined), while the optional initializer is left behind at the point > of the 'var' statement, to be executed only if control flows through > that point. > > I have always agreed with your desire for efficiency, so now I also > agree that the test should be changed. I don't think the CCXML standard > intends to preclude what you want to do (if it does, it should make a > statement to that effect), and the test just exposes an unintended > consequence of breaking a Javascript pgm up into smaller compilation > units. " > > Dan - the above was from your 5/25 email to me. Please chime in. > > Regards, > Chris > > Baggia Paolo wrote: >> Chris, >> >> we reviewed and discussed your comments on CCXML.1.0 scooping. >> >> ISSUE-677: >> >> Proposed Resolution: Reject >> >> In our opinion ISSUE-677 on #798 in 8_4.txml, is correctly testing >> the scope chain of CCXML (in Sect 8.2.1.1). >> >> Where the first 'if' is meant to see if the variable is resolved >> in the 'session' scope, then other scopes are tested as well. >> >> After discussion your request is pending reject. >> >> Please explicitly confirm that you accept the proposed resolution or >> after one week we will consider implicitly accepted the resolution. If >> you need clarification, please ask them very soon. >> >> Regards, >> Paolo >> >> > > -- Dan Evans Invores Systems o. 800-795-2304 c. 516-410-0169 s. sip:5002@sip.invores.com:5062
Received on Monday, 7 June 2010 20:08:38 UTC