This reminds me a lot of Scala macros research. As you probably know, Scala solves code-gen issues with experimental support for several kinds of macros, distinguishing clearly between expression-level and type-level code generation/rewriting. APT covers only a fraction of type-level generation, while GWT.create() covers type-level and a little of expression-level rewriting. In standard JRE applications, expression-level is solved with runtime reflection, but in GWT, we must rely on GWT.create(). We always need expression-level handles to get access to the instances of the generated classes. Take a look at Dagger, injections are generated with APT (type-level) and expression-level handles are done with ObjectGraph by means of runtime reflection:
// APT can't save us here, we need runtime reflection ObjectGraph objectGraph = ObjectGraph.create(new DripCoffeeModule()); APT and GWT.create() are complementary done the lack of runtime reflection support in GWT. In this sense, I think the Ray's proposal is a step forward. We can't get rid off GWT.create(), but we can hide it as possible from end users. Only API authors should treat with GWT.create(). El viernes, 9 de agosto de 2013 20:16:55 UTC-3, Goktug Gokdogan escribió: > > 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. > > 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). > 2. IDE support: IDE can trigger codegen (esp. for debugging) > 3. Parallelizing the compilation and ease moving from JDT into java 8 > compiler plugin. > 4. Reusing knowledge from java world and lower the barrier for entry to > generators. > > > With that move, deferred binding definition for code generator can be just > about providing the naming conventions such as "<class_name> > -> <class_name>$Generated". > Based on the rule, when the compiler sees GWT.create(A.class), it can be > turned into "new A$Generated()" and expect the generated code to be there. > > The reason I'm bringing this up is; for any proposal I think it is best to > keep it feasible w.r.t this aspect and not push us into a corner for the > long run. > > > On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky > <[email protected]<javascript:> > > wrote: > >> Hi, I've published a document [1] with my thoughts on some of the >> GWT.create() proposals. This doesn't cover everything we've discussed but I >> think it's a start. If you're on this mailing list you should be able to >> comment. >> >> - Brian >> >> [1] >> https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AAAAAGXMcRI# >> >> -- >> 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.
