On Tue, Apr 21, 2009 at 12:38 PM, nicolas de loof <nicolas.del...@gmail.com>wrote:
> The only critism I'd have is the requirement to use GWT.create() to get > code from a generator. This is a requirement when the generated code doesn't > extend the source type (for example for Async interfaces) but not when the > genrator is used to add some capabilities (ie acts as a decorator), for > example to add PropertyChangeListener to a model bean. > Perhaps if you could distill down a more concrete example, it could get the wheels turning. Enhancements to GWT.create() certainly aren't off the table. Ray Cromwell has made some pretty useful-sounding suggestions in the past. We just have to find large-group consensus on what makes the most sense, striking a balance between power, clarity, and of course, optimizability. Here's a quick back-of-envelope pattern that could possibly work: class PersonBean { void setName(String name): String getName(); } interface MethodCallLogger { } class MyEntryPoint { class PersonBeanWithMethodCallLogger extends PersonBean implements MethodCallLogger { // empty, but a subclass gets generated } public void onModuleLoad() { // Have a generate-with rule for MethodCallLoggerGenerator, triggered by assignability to "MethodCallLogger" PersonBean pb = GWT.create(PersonBeanWithMethodCallLogger.class); pb.setName("Nicolas"); } } // Generated... class PersonBeanWithMethodCallLoggerImpl extends PersonBeanWithMethodCallLogger { void setName(String name) { someLogger.log("setName('" + name + "') called"); super.setName(name); } ... } As formulated above, this pattern doesn't compose well. But it might be that we can forge a pattern like this into something everyone likes eventually. -- Bruce > > This makes unit testing more difficult as code that uses GWT.create cannot > run in "classic" jUnit. It would be great to have the compiler use > generator-extended classes even when created using the standard "new" > keyword. > > Thanks a lot for the explanation. > Nicolas > > 2009/4/21 Bruce Johnson <br...@google.com> > > A sort of philosophical meta-point that may or may not be of interest... >> >> When we started GWT, we were worried about managing the complexity of >> compile-time code generation, so we tried to find the simplest, most >> easy-to-debug approach we could think of. GWT's model of never changing >> existing code[1], but only adding new Java source during the compile, is >> really a design choice, not a technical limitation. The benefit of the >> current design is that you can add -gen to hosted mode and map the >> corresponding folder into your source path, and then easily step through all >> your code, both handwritten and generated, in the debugger. This avoids >> tricky or confusing situations wherein the source code you see appears to be >> doing something different than the bytecode that's running. It seems good to >> avoid that kind of dichotomy, on the principle that >> straightforward-though-verbose is generally better than fancy-but-confusing. >> >> [1] Overlay types were the first time we ever even did bytecode rewriting, >> and that support is implemented at a very deep level. Also, JSOs are >> intended to be among only a very few "magic" things in GWT (basically, JSNI, >> GWT.create(), GWT.runAsync(), and JSOs). We went to a lot of effort to >> ensure that JSOs worked according to a fixed set of rules that are not hard >> to comply with, even if people don't fully understand why the implementation >> requires it. >> >> >> On Mon, Apr 20, 2009 at 11:11 AM, Thomas Broyer <t.bro...@gmail.com>wrote: >> >>> >>> >>> >>> On 20 avr, 08:43, nicolas de loof <nicolas.del...@gmail.com> wrote: >>> > > > I wonder if there is any way to also "pre-process" Java sources, >>> for >>> > > example >>> > > > this would enable support for Aspect Oriented Programming or maybe >>> some >>> > > > DataBinding framework. >>> > >>> > > Depends what you mean by "pre-process"... Generally, generators >>> > > analyze the class they're called for (for example, looking for >>> > > specific annotations on methods or on the class itself) and according >>> > > to this generate a Java class extending the one they've been called >>> > > for. >>> > > (is this understandable? is this at least no-so-bad english?) >>> > >>> > In many case the generator will create from MyClassX some MyClassXImpl >>> or >>> > equivalent that extends the original one, bu not REPLACE it as Java >>> source. >>> > This is what I mean by "pre-process". >>> > >>> > For example, to implement a AOP framework I'd like to instrument all >>> calls >>> > to some method. For this reason I'd like a generator / pre-processor to >>> > check the source files and detect the matching pointcuts to add some >>> adived >>> > code. Many other example can apply, including annotation processing for >>> > declarative coding (ex : @Property annotation to automagically >>> introduce the >>> > required PropertyChangeListeners) >>> >>> You would generate a subclass that delegates to super.method() after/ >>> before the aspect(s) code. >>> >>> > I never tried it myself, but I'n not sure a generator can REPLACE the >>> > original Java Source. >>> >>> AFAICT, it can't, but there's probably no need for this. >>> >>> > I may be wrong but I also thing the generated code is >>> > only available when using GWT.create(), >>> >>> The generator is only called at the point where GWT.create() is called >>> (I may be wrong but you could generate a different output for each >>> GWT.create() call-point for the same class literal), so yes, you're >>> right. >>> >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---