On Fri, Aug 9, 2013 at 7:16 PM, Goktug Gokdogan <[email protected]> wrote:

> I think in the long-run we should separate the two concepts that is being
> tackled by GWT.create today.
>
> First purpose is the class replacement, especially used by permutations. I
> think this one should not have anything to do with GWT.create. We can do
> any class replacement in compiler without requiring a call to GWT.create.
> This is similar to super-sourcing and can be solved similar and perhaps
> together.
>

I don't see how it is similar to super-sourcing, as you need to dynamically
select which class goes on there. For example, think about implementing
GWT.create(SomeLocalizableSubclass).  There are hundreds of locales, and
different classes are going to have different implementations so you have
to make the substitution decision for each one of them separately.

Are you proposing to hook new Foo and substituting the class?  Where does
the compiler get the knowledge to know which class to substitute?  I don't
think you want to build all the knowledge of the ClientBundle generator
into the compiler, for example.


> Second purpose is for triggering generators and what most of the proposal
> are about.
>
> As Roberto and perhaps others have been bringing up, it is best to follow
> regular java code generation practices in GWT.
>
> That means for the long-term we can mostly rely on AnnotationProcessors.
> There are many advantages of that:
>   1. Not GWT only - continue sharing code with server (JRE), client(GWT)
> and mobile(Android).
>

You can use shared.GWT.create today in all those environments.


>    2. IDE support: IDE can trigger codegen (esp. for debugging)
>

My experience with this has been pretty poor, and running GWT with -gen is
at least as useful.

-- 
John A. Tamplin

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


Reply via email to