http://gwt-code-reviews.appspot.com/77810/diff/34/1016 File user/src/com/google/gwt/core/client/impl/Impl.java (right):
http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode148 Line 148: _ = jsFunction.apply(thisObj, arguments); On 2009/10/13 19:13:43, scottb wrote: > What's the motivation for this change? Declaring a temporary variable in the else block resulted in the following web-mode code: function apply() { return jsFunction.apply(thisObj, arguments); var toReturn; } Looks like we need something to reallocate js-local variables and prune unused ones. Is that something that RayC would be working on? http://gwt-code-reviews.appspot.com/77810/diff/34/1016#newcode163 Line 163: if (hasEntered) { When we did the emulated JS stack trace work, we decided to treat the reentrancy situation as though it were one big stack. I think the same thing applies here. You might really, really hope that you're code doesn't hit a reentrancy situation, but we really can't mask what the browser is actually doing. If you really care about masking it, that could be done at a higher-level API. Re: FinallyCommand, the way Joel and I have been defining it, it's spec'ed to execute after all use code, but just before we release back to the browser's event queue. In my mind, that means that FinallyCommands enqueued in reentrant case execute in the same batch as those enqueued in the outermost execution context. @Joel, will you be the decider? What's going to make the most sense (if anything makes sense at all anymore)? http://gwt-code-reviews.appspot.com/77810 --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
