Now that I understand it (hopefully), I think Ray's proposal is a good way to define new API's by writing Java wrappers that configure generated objects at runtime. Adding parameters to GWT.create() calls seems somewhat orthogonal as a way to pass arguments to generators at compile time.
As often happens with language extensions, when you put them together, things get more complicated but also more expressive; if GWT.create() takes extra arguments then these should also be literals that you can accept in a user-defined create method. On Sat, Aug 10, 2013 at 12:35 PM, Andrés Testi <[email protected]>wrote: > 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/** >>>> 1MDqiBEMl7dylYliAceLBBxGFAlSvk**QB9b-kSlnKmZBk/edit?disco=** >>>> AAAAAGXMcRI#<https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AAAAAGXMcRI#> >>>> >>>> -- >>>> http://groups.google.com/**group/Google-Web-Toolkit-**Contributors<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 google-web-toolkit-**contributors+unsubscribe@** >>>> googlegroups.com. >>>> For more options, visit >>>> https://groups.google.com/**groups/opt_out<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. > > > -- 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.
