Gotcha, neato. Is that explanation actually in the blog post you linked to?
On Sat, Feb 13, 2010 at 3:22 PM, Ray Cromwell <[email protected]> wrote: > I'm not sure how my proposal creates more boilerplate, it adds the > ability to specify arbitrary parameters to GWT.create, e.g. > > GWT.create(A.class, LiteralParam1, LiteralParam2, ...) > > That's the first thing it does which is the same as your proposal. The > generator can then look at the supplied parameters as well as the > requested type. > > The second thing it allows you to do is bless any static method method > of your choice as a GWT.create() equivalent. Consider the identity > case: > > public class MyLibrary { > @GwtCreate > public static <T> T create(Class<?> clazz) { > return GWT.create(clazz); > } > } > > Usage: > > MyLibrary.create(Binder.class); > > That is, you make cause any static method of the right signature to > have the same compile time constraints as GWT.create(), with the added > bonus that you may invoke GWT.create() inside of such methods with > non-literal parameters, because the enclosing method parameters are > guaranteed to be literals. > > I think I provided more than enough use-cases to justify why you'd > want this. Currently, GWT.create() has many problems besides lack of > parameterization: > > 1) Return type is not statically checked, so one cannot write > type-safe methods that invoke GWT.create() > 2) One can't check parameters to GWT.create(), so for example, if you > want to create a UIBinder, and you accidently pass a non-UIBinder > type, it silently gets deferred bound, and you won't catch the error > until runtime when the cast is attempted. > 3) If a class has more than 2 tagging interfaces, you can't decide > which generator to run. > > The current situation makes it very hard to write idiomatic Java > helper functions with proper type signatures and forces one to > sprinkle GWT.create() calls through out one's code because you can't > delegate creation. > > -Ray > > On Sat, Feb 13, 2010 at 3:09 PM, Ray Ryan <[email protected]> wrote: > > My goal is less boilerplate. While this looks cool and offers more > > flexibility, it takes me farther from that goal. These seem like > orthogonal > > concerns to me. > > > > On Sat, Feb 13, 2010 at 3:05 PM, Ray Cromwell <[email protected]> > wrote: > >> > >> Ray, I like this idea, but I feel it is not general enough to cover > >> all the use cases. Now that Bob has added support for Annotations in > >> the AST, I feel like it is time to revive this proposal: > >> > >> > >> > http://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html > >> > >> Which covers your case, but also the general case of writing library > >> functions that can provide better type signatures that GWT.create(), > >> as well as the ability to override the type of generator run. > >> > >> It wouldn't be hard to implement, the first time I looked at > >> implementing it, it was actually lack of annotations in the AST that > >> was a road block. > >> > >> -Ray > >> > >> > >> On Sat, Feb 13, 2010 at 12:51 PM, Ray Ryan <[email protected]> wrote: > >> > I hate the boilerplate required in UiBinder owners: > >> > > >> > interface MyBinder extends UiBinder<Widget, Me>; > >> > private static final MyBinder binder = GWT.create(MyBinder.class); > >> > > >> > A two part fix comes to mind. Create a two argument overload of > >> > GWT.create, > >> > and eliminate one of the type params for UiBinder. > >> > > >> > /** Create an instance of T tailored to the needs of forClass */ > >> > public static <T> T create(Class<?> makeClass, Class<?> forClass) > >> > > >> > That lets me tell the Foo generator to create, say, a Foo<Bar> for my > >> > Bar to > >> > use. Or a Foo_Impl_For_Bar. Or whatever. The point is that I'm > providing > >> > two > >> > keys to the generator. The first determines what generator is run, > just > >> > as > >> > today, and the optional second gives me channel to pass configuration > >> > information to the generator without being forced to extend an > interface > >> > or > >> > abstract class that isn't useful to me. > >> > On the UiBinder side, we can relax the arbitrary requirement that > >> > <UiBinder> > >> > have a single child and make the create...() method have a void > return. > >> > For > >> > backward compatibility, we introduce a new super interface with these > >> > changes: > >> > > >> > interface UiBinder<U, O> extends Binder<U, O> { ... } > >> > interface Binder<O> { > >> > void createFor(O owner); > >> > } > >> > > >> > With this, we can reduce binder boilerplate to > >> > > >> > private static final Binder = GWT.create(UiBinder.class, Me.class); > >> > > >> > Well? > >> > rjrjr > >> > > >> > -- > >> > I wish this were a Wave > >> > > >> > -- > >> > http://groups.google.com/group/Google-Web-Toolkit-Contributors > >> > >> -- > >> http://groups.google.com/group/Google-Web-Toolkit-Contributors > > > > > > > > -- > > I wish this were a Wave > > > > -- > > http://groups.google.com/group/Google-Web-Toolkit-Contributors > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > -- I wish this were a Wave -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
