On 4/6/2011 3:22 PM, P T Withington wrote:
Oh dear, I suspect the answer is not good. Is it as bad as 4 and 3?
Right answers, applause! ;-)
I'm going to guess that because `is` is expanded to handle our mixins, more
blocks that you'd like, and probably the right-hand side of the expression is
evaluated more than once, when it should not be.
JavascriptGenerator#{visitPrefixExpression, visitPostfixExpression,
visitAssignmentExpression}() expands the expression if there are free
references. Based on the comments in those methods the expansion is
(was?) necessary to support the "undefined reference checker":
// The undefined reference checker needs to have this expanded
// to work
The whole "undefined reference checker" thing seems to be some kind of
CodeGenerator leftover...
Perhaps with Don's additional class model information now available at
compile-time, we can make a much more intelligent decision here (at least in
the case where the rhs is a known class). And in the general case, we should
just use a subroutine call, rather than trying to inline at all?
The inlining in JavascriptGenerator#visitBinaryExpressionSequence() is a
bit too aggressive, it doesn't account for any kind of expressions, or
getters with side-effects, etc.
On 2011-04-06, at 08:48, André Bargull wrote:
How many try-catch blocks will be generated by the following program?
1) 0 blocks
2) 1 block
3) 3 blocks
4) 12 blocks
Extra Question:
What is the final value of "i" if "i" was initialized with 0?
1) 0
2) 1
3) 2
<canvas>
<script when="immediate">
#pragma "warnUndefinedReferences=true"
#pragma "catchFunctionExceptions=true"
a is b[i+=1]
</script>
</canvas>
