I miss this line in my dagger example: CoffeeApp coffeeApp = objectGraph.get(CoffeeApp.class);
El sábado, 10 de agosto de 2013 16:23:50 UTC-3, Andrés Testi escribió: > > 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]>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] >>> . >>> 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.
