(2) sounds reasonable. But, what are the consequences of disallowing (1)? Would it mean that anonymous classes can no longer have jsni code?
Amit On Wed, Feb 11, 2009 at 2:41 PM, John Tamplin <j...@google.com> wrote: > On Wed, Feb 11, 2009 at 2:19 PM, Scott Blum <sco...@google.com> wrote: > >> Some of our future plans for speeding up hosted mode significantly involve >> using class files already compiled by javac or an IDE rather than always >> compiling everything fresh from source. However, we've run into some >> problems where different compilers can follow different conventions on how >> anonymous classes are handled. >> >> This is causing difficulties in two specific areas: >> 1) Modeling anonymous inner classes in TypeOracle. >> 2) Referencing anonymous inner classes from JSNI. >> >> I propose that we deprecate both of these features in 1.6, and remove them >> in 2.0. We were able to support this in the past by having complete control >> of the compiler toolchain (JDT only) at the cost of a lot of runtime >> overhead. But looking back, I now question the wisdom of allowing >> references to things that, by definition, don't even have a name. >> > > I think removing JSNI references to anonymous classes is fine, but I am not > sure about removing them from TypeOracle. I think a generator can already > not rely on the generated classname so I don't see a problem if there is > further variability, but it should be able to know that it exists. I > believe some code currently uses anonymous classes for Messages interfaces, > and it would seem bad to break that without good reason. > > While we are on the subject, I think we should choose either source or > binary names for JSNI rather than allowing both. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
