On Mon, Oct 6, 2008 at 4:55 PM, Mike Aizatsky <[EMAIL PROTECTED]>wrote:
> > Gotcha. But if you don't compile multiple times, how do you prevent > > optimizations that occur in one test method from impacting ones that > occur > > in another test method? > > I can't. I do this by limiting the scope optimization should work on > (see MethodInlineTest)... > Gotcha. > > By the way, I've already got a big patch out that Bob is reviewing that > is a > > huge refactor to JavaToJavaScriptCompiler, and we can continue to > refactor > > further to support this use case in the best way possible. I can't think > of > > a fundamental reason that compiles should be slow for small test cases. > > I'll be happy to take a look at JTJSC and tests as soon as you finish > the refactoring. > Cool, if you want, you can chime in on the patch review for that. > >> You mean storing diffs instead of expected data? > > > > Something like that. > > As a second thought, I don't feel that will help much. If you change a > compiler, in a way, that changes "interesting" code - you'll be in the > same position. And it's much more difficult to look at diffs than at > expected text. > > Probably we could limit expected test scope? Say to a specified method(s)? > Yeah, that sounds good. Scott --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
