Maybe it would make sense to move properties which the compiler relies on into a special CompilerFlags.gwt.xml module, then if you want to change class meta data, class cast checking, aggressive optimization, or stack info, there'd be one centralized place to look at and document all the flags.?
-Ray On Fri, Oct 30, 2009 at 9:31 PM, Bruce Johnson <[email protected]> wrote: > > I wish we could wrap that all up in a simpler-to-understand package. > But a good article would make it at least bearable. > > On Saturday, October 31, 2009, Ray Cromwell <[email protected]> wrote: > > > > > > On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson <[email protected]> wrote: > > > > > > In terms of design, I think this would actually be best as a > permutation-specific conditional deferred binding property that the compiler > is sensitive to (that was a mouthful), so that it would be possible to let > app developers control how many stack trace-enabled users there are, in the > same way they can control how many users get the expensive emulated stack > traces on IE. I would guess something like <= 10% would need stack traces > enabled to still get good stats. > > > > Perhaps we can think of it as a tri-state variable: strip stack info, > browser supplied stack info, emulated stack info. Choose per permutation. > > -Ray > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
