I like it! I've got a few comments / ideas, but overall, I'm glad to see more work being done to empower core GWT functionality.
> Note that the @GwtCreate class parameters aren't replaced by > GwtCreateFactory as was originally suggested by Ray Cromwell. This provides > access to actual parameters. > > It would be possible to do a full replacement if the factory also gave access to the class field, and any code in the method block accessing the class could be re-routed through the factory. Though, I see no good reason why to do the extra work this way, I figured I'd mention it in case someone else has a use case for it. * Upcoming improvements: > > 1) Support for explicit generators > > @GwtCreate(generator = FooGenerator.class) > > Did you see my pull request with some (very) basic support for this? https://gwt-review.googlesource.com/#/c/4000/ > We should forbid assignation between parameters that differs in > @GwtCreate signature > > Foo createFoo(@GwtCreate(generator = FooGen.class) final Class<? > extends Foo>) {...} > > Agreed. Final isn't necessary to trace values, but it does ensure users don't get weird behavior. 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param > > <U, O> UiBinder<U, O> createBinder( > @GwtCreate(generator = UiBinGen.class) final Class<U> uiType, > @GwtCreate.Param final Class<O> ownerType) { > Is the intention here to just send more classes to the generator, or to actually send parameters to the constructor of the rebound object being instantiated? Foo createFoo( @GwtCreate final Class<? extends Foo> fooType, @GwtCreate.Param final Class<?> arg1, @GwtCreate.Param final Class<?> arg2) { return GWT.create(fooType, arg1, arg2); } Sending classes is no good, because the constructor needs the values. Personally, I think the best solution is to add the parameters to @GwtCreate; Foo createFoo( @GwtCreate({String.class, int.class}) final Class<? extends Foo> fooType, String arg1, int arg2) { return GWT.create(fooType, arg1, arg2); } Class values in annotations must be class literals, so that makes that easy. It also means we don't care about the order of extra parameters sent to the method, nor are we forced to get these values from the method parameters (or even declare GWT.create params as params in method); the invocation of GWT.create(cls, params) would simply supply the JExpressions to pass along to constructors. (Have to pull out the initializers from the JNewArray made by the generics, but that's simple). I assume we would be changing GWT.create to be create(Class<?> c, Object ... params); the compiler could bail if params.length > 0 anywhere that's not in a method (method w/ parameter) annotated with @GwtCreate. Then, add a JType[] and JExpression[] to JGwtCreate to be able to find the right constructor and have values to send it (not sure if unboxing would work without a tweak, but that's no biggie). The only hard-ish part would be updating ResolveRebinds to pass along the list of JExpressions correctly. Do you have any work started in this area, cos I'd be glad to give it a shot / send over a pull request. To allow mixed multiple code-gen parameters, we would bind main parameters by name > > <F extends Foo, B extends Bar> > void mixedMultiple( > @GwtCreate final Class<F> fooType, > @GwtCreate.Param("fooType") final Class<?> fooArg, > @GwtCreate final Class<B> barType, > @GwtCreate.Param("barType") final Class<?> barArg) > I really don't like this much typing to wire stuff up. Putting the params in the @GwtCreate would make this much cleaner: <F extends Foo, B extends Bar> B create( @GwtCreate({String.class}) final Class<F> fooType, @GwtCreate({Foo.class}) final Class<B> barType) { F foo = GWT.create(fooType, "some string"); return GWT.create(barType, foo); // params can come from anywhere } > 3) Support for GWT.create(this.getClass()) ? not exactly, but... > > Explicits generators can eliminate the issue of the unique generator > per class hierarchy. An aditional boolean parameter for @GwtCreate would > mitigate the code size issue > > abstract class UiBinderComposite extends UiBinderComposite { > > public UiBinderComposite() { > UiBinder<Widget, UiBinderComposite> binder = > createBinder(getClass()); > } > > private static UiBinder<Widget, UiBinderComposite> > createBinder(@GwtCreate( > // The explicit generator knows when to stop the code > generation > generator = UiBinderCompositeGenerator.class, > > // this.getClass() is disallowed by default. > allowsThisClass = true) > final Class<? extends UiBinderComposite> type) { > > return GWT.create(type); > } > } > I am unsure how a param in @GwtCreate on the method affects enhancing this classes. Would it enhance the this of the type sent to the method? It seems like this is behavior that should be defined on the types themselves, and not at the call site where they are used... Though, I guess it would be easier to prune the enhancement that way. > I can formalize all of these in a document if you agree. > > I think a design spec on something this big, with so many side effects is a good idea, and I'd be glad to help. All in all, great stuff! Even if these kinds of enhancements don't make it into master right away, at least having them in a functional state makes it possible to play with and develop the extended functionality. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
