yep, and all of them should be per-perm On Saturday, October 31, 2009, Ray Cromwell <cromwell...@gmail.com> wrote: > 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 <br...@google.com> 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 <cromwell...@gmail.com> wrote: >> >> >> On Fri, Oct 30, 2009 at 8:24 PM, Bruce Johnson <br...@google.com> 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 -~----------~----~----~----~------~----~------~--~---
