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
-~----------~----~----~----~------~----~------~--~---
