Thanks for the reply - I'll keep watching ;). W.R.T. designer, since existing installs are already broken and GWT 3+ is going to again remove these deprecated methods, wouldn't it make more sense to upgrade designer rather than downgrade ModuleDefLoader/DOM? (Keeping in mind that I don't know what other upcoming changes are coming, but I'm assuming that code like ModuleDefLoader will eventually have some advantages from the context objects, and designer can't just keep using this now-deprecated method forever.)
On Monday, February 10, 2014 3:02:00 PM UTC-8, John Stalcup wrote: > > > > > On Mon, Feb 10, 2014 at 2:57 PM, Colin Alworth <[email protected]<javascript:> > > wrote: > >> Just watched https://gwt-review.googlesource.com/#/c/6342/ wander by, >> but I've also seen this trying to understand the general compiler changes >> that are happening in trunk gwt - is the CompilerContext really an >> essential part of ModuleDefLoader in general? From what I can see it is >> tracked as a local variable, but only used in the enforceStrictResources() >> check, which could just as easily be a boolean. For any synthetic module >> (which can't have any resources at all), this is a moot point so the >> context could be skipped entirely, and more generally it *seems* to just be >> a flag. >> > not all changers are in. there are more uses coming. > >> >> CompilationStateBuilder uses it to read out a 'suppressErrors' flag, and >> passes it to the JdtCompiler, which doesn't actually use it at all - that >> seems to be the extent of its use when you do a >> ModuleDef.getCompilationState (which now requires that context as an >> argument, even though the ModuleDef already should have that state from the >> previously mentioned ModuleDefLoader?). Precompile takes it to get the >> module and the options (instead of taking the module and the options), and >> the J2JSCompiler takes it just to read options. >> >> At least as of 2.6 branch, haven't done the same tracing through master >> just yet. >> >> So my question is two-fold: Is this the new way of avoiding too many sets >> of config types to track, and if so, why restore the old APIs so that the >> designer can use them in 2.6.1 instead of updating the designer to generate >> a simple context for its own needs? >> > updating the designer code would leave existing designer installs broken. > > >> Assuming this is the future way of dealing with options/etc, won't the >> designer just break again as this becomes more and more necessary to hook >> into the compiler from outside? >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> You received this message because you are subscribed to the Google Groups >> "GWT Contributors" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to >> [email protected]<javascript:> >> . >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
