[gwt-contrib] Initial support for @GwtCreate (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I apologize for not to post this in the "Possible GWT.create() Improvements" thread, but this message is too long to be only a comment. You can check my patch at https://gwt-review.googlesource.com/4110. This prototype has passed many JUnit tests cases and works fine (only fails JEnumTypeTest after my last pull, I don't know why). Devmode also works. This proposal differs from Ray's original idea in that @GwtCreate is a parameter annotation instead of a method annotation. Later I will justify this decision. This new proposal consists on rewriting methods adding a trailing implicit parameter of type GwtCreateFactory for each parameter annotated with @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler: interface GwtCreateFactory { T create(); } When the compiler finds a code-gen method like Foo createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } it is rewritten as Foo createFoo(final Class type, GwtCreateFactory fooType$factory) { return fooType$factory.create(); } IMPORTANT: The @GwtCreate parameter requires to be final. This proposal doesn't require constant evaluation expression. The final modifier is required to disable non reproductible side effects. At method call site, an invocation like Foo foo = createFoo(SubFoo.class); is rewritten as class SubFoo$GwtCreateFactory implements GwtCreateFactory { @Override public T create() { return GWT.create(SubFoo.class); } } Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory()); Just like Scala implicit parameters, @GwtCreate can fight against type erasure and subtyping interface FooCreator { T create(@GwtCreate Class fooType); } class FooCreatorImpl extends FooCreator { T create(@GwtCreate final Class fooType) { return GWT.create(fooType); } } code-gen constructors are supported too class CreateByConstructor { final T instance; public CreateByConstructor(@GwtCreate final Class fooType) { instance = GWT.create(fooType); } } Again, as in Scala implicit parameters, nesting is allowed class Foo {} class SubFoo extends Foo {} F createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } S createSubFoo(@GwtCreate final Class subFooType) { return createFoo(subFooType); } The decision to locate @GwtCreate on parameters was taken to support mixed code-gen methods void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final Class barType) { foo = GWT.create(fooType); bar = GWT.create(barType); } Note that the @GwtCreate class parameters aren't replaced by GwtCreateFactory as was originally suggested by Ray Cromwell. This provides access to actual parameters. Class storedType; T instance; void createFoo(@GwtCreate final Class type) { storedType = type; instance = GWT.create(type); } * Further improvements: 1) Support for explicit generators @GwtCreate(generator = FooGenerator.class) We should forbid assignation between parameters that differs in @GwtCreate signature Foo createFoo(@GwtCreate(generator = FooGen.class) final Class) {...} // This will fail Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final Class fooType) { return createFoo(fooType); } 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param UiBinder createBinder( @GwtCreate(generator = UiBinGen.class) final Class uiType, @GwtCreate.Param final Class ownerType) { return GWT.create(uiType, ownerType); } @GwtCreate.Params must respect the same kind of signature rules than @GwtCreate, and a strict order of invocation // Good ordering Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg1, arg2); } // Bad ordering, this will fail Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg2, arg1); } To allow mixed multiple code-gen parameters, we would bind main parameters by name void mixedMultiple( @GwtCreate final Class fooType, @GwtCreate.Param("fooType") final Class fooArg, @GwtCreate final Class barType, @GwtCreate.Param("barType") final Class barArg) 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 s
[gwt-contrib] Initial support for @GwtCreate parameters (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I apologize for not to post this in the "Possible GWT.create() Improvements" thread, but this message is too long to be only a comment. You can check my patch at https://gwt-review.googlesource.com/4110. This prototype has passed many JUnit tests cases and works fine. Devmode also works. This proposal differs from Ray's original idea in that @GwtCreate is a parameter annotation instead of a method annotation. Later I will justify this decision. This new proposal consists on rewriting methods adding a trailing implicit parameter of type GwtCreateFactory for each parameter annotated with @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler: interface GwtCreateFactory { T create(); } When the compiler finds a code-gen method like Foo createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } it is rewritten as Foo createFoo(final Class type, GwtCreateFactory fooType$factory) { return fooType$factory.create(); } IMPORTANT: The @GwtCreate parameter requires to be final. This proposal doesn't require constant evaluation expression. The final modifier is required to disable non reproductible side effects. At method call site, an invocation like Foo foo = createFoo(SubFoo.class); is rewritten as class SubFoo$GwtCreateFactory implements GwtCreateFactory { @Override public T create() { return GWT.create(SubFoo.class); } } Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory()); Just like Scala implicit parameters, @GwtCreate can fight against type erasure and subtyping interface FooCreator { T create(@GwtCreate Class fooType); } class FooCreatorImpl extends FooCreator { T create(@GwtCreate final Class fooType) { return GWT.create(fooType); } } code-gen constructors are supported too class CreateByConstructor { final T instance; public CreateByConstructor(@GwtCreate final Class fooType) { instance = GWT.create(fooType); } } Again, as in Scala implicit parameters, nesting is allowed class Foo {} class SubFoo extends Foo {} F createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } S createSubFoo(@GwtCreate final Class subFooType) { return createFoo(subFooType); } The decision to locate @GwtCreate on parameters was taken to support mixed code-gen methods void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final Class barType) { foo = GWT.create(fooType); bar = GWT.create(barType); } Note that the @GwtCreate class parameters aren't replaced by GwtCreateFactory as was originally suggested by Ray Cromwell. This provides access to actual parameters. Class storedType; T instance; void createFoo(@GwtCreate final Class type) { storedType = type; instance = GWT.create(type); } * Further improvements: 1) Support for explicit generators @GwtCreate(generator = FooGenerator.class) We should forbid assignation between parameters that differs in @GwtCreate signature Foo createFoo(@GwtCreate(generator = FooGen.class) final Class) {...} // This will fail Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final Class fooType) { return createFoo(fooType); } 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param UiBinder createBinder( @GwtCreate(generator = UiBinGen.class) final Class uiType, @GwtCreate.Param final Class ownerType) { return GWT.create(uiType, ownerType); } @GwtCreate.Params must respect the same kind of signature rules than @GwtCreate, and a strict order of invocation // Good ordering Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg1, arg2); } // Bad ordering, this will fail Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg2, arg1); } To allow mixed multiple code-gen parameters, we would bind main parameters by name void mixedMultiple( @GwtCreate final Class fooType, @GwtCreate.Param("fooType") final Class fooArg, @GwtCreate final Class barType, @GwtCreate.Param("barType") final Class barArg) 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 UiBind
[gwt-contrib] Initial support for @GwtCreate (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I apologize for not to post this in the "Possible GWT.create() Improvements" thread, but this message is too long to be only a comment. You can check my patch at https://gwt-review.googlesource.com/4110. This prototype has passed many JUnit tests cases and works fine (only fails JEnumTypeTest after my last pull, I don't know why). Devmode also works. This proposal differs from Ray's original idea in that @GwtCreate is a parameter annotation instead of a method annotation. Later I will justify this decision. This new proposal consists on rewriting methods adding a trailing implicit parameter of type GwtCreateFactory for each parameter annotated with @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler: interface GwtCreateFactory { T create(); } When the compiler finds a code-gen method like Foo createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } it is rewritten as Foo createFoo(final Class type, GwtCreateFactory fooType$factory) { return fooType$factory.create(); } IMPORTANT: The @GwtCreate parameter requires to be final. This proposal doesn't require constant evaluation expression. The final modifier is required to disable non reproductible side effects. At method call site, an invocation like Foo foo = createFoo(SubFoo.class); is rewritten as class SubFoo$GwtCreateFactory implements GwtCreateFactory { @Override public T create() { return GWT.create(SubFoo.class); } } Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory()); Just like Scala implicit parameters, @GwtCreate can fight against type erasure and subtyping interface FooCreator { T create(@GwtCreate Class fooType); } class FooCreatorImpl extends FooCreator { T create(@GwtCreate final Class fooType) { return GWT.create(fooType); } } code-gen constructors are supported too class CreateByConstructor { final T instance; public CreateByConstructor(@GwtCreate final Class fooType) { instance = GWT.create(fooType); } } Again, as in Scala implicit parameters, nesting is allowed class Foo {} class SubFoo extends Foo {} F createFoo(@GwtCreate final Class fooType) { return GWT.create(fooType); } S createSubFoo(@GwtCreate final Class subFooType) { return createFoo(subFooType); } The decision to locate @GwtCreate on parameters was taken to support mixed code-gen methods void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final Class barType) { foo = GWT.create(fooType); bar = GWT.create(barType); } Note that the @GwtCreate class parameters aren't replaced by GwtCreateFactory as was originally suggested by Ray Cromwell. This provides access to actual parameters. Class storedType; T instance; void createFoo(@GwtCreate final Class type) { storedType = type; instance = GWT.create(type); } * Upcoming improvements: 1) Support for explicit generators @GwtCreate(generator = FooGenerator.class) We should forbid assignation between parameters that differs in @GwtCreate signature Foo createFoo(@GwtCreate(generator = FooGen.class) final Class) {...} // This will fail Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final Class fooType) { return createFoo(fooType); } 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param UiBinder createBinder( @GwtCreate(generator = UiBinGen.class) final Class uiType, @GwtCreate.Param final Class ownerType) { return GWT.create(uiType, ownerType); } @GwtCreate.Params must respect the same kind of signature rules than @GwtCreate, and a strict order of invocation // Good ordering Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg1, arg2); } // Bad ordering, this will fail Foo createFoo( @GwtCreate final Class fooType, @GwtCreate.Param final Class arg1, @GwtCreate.Param final Class arg2) { return GWT.create(fooType, arg2, arg1); } To allow mixed multiple code-gen parameters, we would bind main parameters by name void mixedMultiple( @GwtCreate final Class fooType, @GwtCreate.Param("fooType") final Class fooArg, @GwtCreate final Class barType, @GwtCreate.Param("barType") final Class barArg) 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
[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)
I forgot to upload the @GwtCreate annotation. You can find It here https://gwt-review.googlesource.com/#/c/4111/ Regards - Andrés El viernes, 16 de agosto de 2013 06:30:15 UTC-3, Andrés Testi escribió: > > I've been working on a prototype inspired by Ray Cromwell's proposal for > @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I > apologize for not to post this in the "Possible GWT.create() Improvements" > thread, but this message is too long to be only a comment. > You can check my patch at https://gwt-review.googlesource.com/4110. This > prototype has passed many JUnit tests cases and works fine (only fails > JEnumTypeTest after my last pull, I don't know why). Devmode also works. > This proposal differs from Ray's original idea in that @GwtCreate is a > parameter annotation instead of a method annotation. Later I will justify > this decision. > This new proposal consists on rewriting methods adding a trailing implicit > parameter of type o for each parameter annotated with @GwtCreate. > GwtCreateFactory is a hidden interface used by the compiler: > > interface GwtCreateFactory { > T create(); > } > > When the compiler finds a code-gen method like > > Foo createFoo(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > > it is rewritten as > > Foo createFoo(final Class type, GwtCreateFactory > fooType$factory) { > return fooType$factory.create(); > } > > IMPORTANT: > The @GwtCreate parameter requires to be final. > This proposal doesn't require constant evaluation expression. The > final modifier is required to disable non reproductible side effects. > > At method call site, an invocation like > > Foo foo = createFoo(SubFoo.class); > > is rewritten as > > class SubFoo$GwtCreateFactory implements GwtCreateFactory { > @Override public T create() { > return GWT.create(SubFoo.class); > } > } > > Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory()); > > Just like Scala implicit parameters, @GwtCreate can fight against type > erasure and subtyping > > interface FooCreator { > > T create(@GwtCreate Class fooType); > } > > class FooCreatorImpl extends FooCreator { > > T create(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > } > > code-gen constructors are supported too > > class CreateByConstructor { > > final T instance; > > public CreateByConstructor(@GwtCreate final Class fooType) { > instance = GWT.create(fooType); > } > } > > Again, as in Scala implicit parameters, nesting is allowed > > class Foo {} > class SubFoo extends Foo {} > >F createFoo(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > >S createSubFoo(@GwtCreate final Class subFooType) { > return createFoo(subFooType); > } > > The decision to locate @GwtCreate on parameters was taken to support mixed > code-gen methods > > > void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final > Class barType) { > foo = GWT.create(fooType); > bar = GWT.create(barType); > } > > Note that the @GwtCreate class parameters aren't replaced by > GwtCreateFactory as was originally suggested by Ray Cromwell. This provides > access to actual parameters. > > Class storedType; > T instance; > > void createFoo(@GwtCreate final Class type) { > storedType = type; > instance = GWT.create(type); > } > > * Upcoming improvements: > > 1) Support for explicit generators > > @GwtCreate(generator = FooGenerator.class) > > We should forbid assignation between parameters that differs in > @GwtCreate signature > > Foo createFoo(@GwtCreate(generator = FooGen.class) final Class extends Foo>) {...} > > // This will fail > Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final > Class fooType) { > return createFoo(fooType); > } > > 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param > >UiBinder createBinder( > @GwtCreate(generator = UiBinGen.class) final Class uiType, > @GwtCreate.Param final Class ownerType) { > > return GWT.create(uiType, ownerType); > } > > @GwtCreate.Params must respect the same kind of signature rules than > @GwtCreate, and a strict order of invocation > > // Good ordering > Foo createFoo( > @GwtCreate final Class fooType, > @GwtCreate.Param final Class arg1, > @GwtCreate.Param final Class arg2) { > return GWT.create(fooType, arg1, arg2); > } > > // Bad ordering, this will fail > Foo createFoo( > @GwtCreate final Class fooType, > @GwtCreate.Param final Class arg1, > @GwtCreate.Param final Class arg2) { > > return GWT.create(fooType, arg2, arg1); > } > > To allow mixed multiple code-gen parameters, we would bind main > paramet
[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)
JEnumTypeTest doesn't fails anymore, I think the issue was solved yesterday :-) -- 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.
Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)
Andres, this looks amazing! I've been out this week on vacation but returning tomorrow, I'll take a look when I return. On Fri, Aug 16, 2013 at 2:22 AM, Andrés Testi wrote: > I've been working on a prototype inspired by Ray Cromwell's proposal for > @GwtCreate parameters, borrowing some ideas from Scala implicit macros. I > apologize for not to post this in the "Possible GWT.create() Improvements" > thread, but this message is too long to be only a comment. > You can check my patch at https://gwt-review.googlesource.com/4110. This > prototype has passed many JUnit tests cases and works fine (only fails > JEnumTypeTest after my last pull, I don't know why). Devmode also works. > This proposal differs from Ray's original idea in that @GwtCreate is a > parameter annotation instead of a method annotation. Later I will justify > this decision. > This new proposal consists on rewriting methods adding a trailing implicit > parameter of type GwtCreateFactory for each parameter annotated with > @GwtCreate. GwtCreateFactory is a hidden interface used by the compiler: > > interface GwtCreateFactory { > T create(); > } > > When the compiler finds a code-gen method like > > Foo createFoo(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > > it is rewritten as > > Foo createFoo(final Class type, GwtCreateFactory > fooType$factory) { > return fooType$factory.create(); > } > > IMPORTANT: > The @GwtCreate parameter requires to be final. > This proposal doesn't require constant evaluation expression. The > final modifier is required to disable non reproductible side effects. > > At method call site, an invocation like > > Foo foo = createFoo(SubFoo.class); > > is rewritten as > > class SubFoo$GwtCreateFactory implements GwtCreateFactory { > @Override public T create() { > return GWT.create(SubFoo.class); > } > } > > Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory()); > > Just like Scala implicit parameters, @GwtCreate can fight against type > erasure and subtyping > > interface FooCreator { > > T create(@GwtCreate Class fooType); > } > > class FooCreatorImpl extends FooCreator { > > T create(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > } > > code-gen constructors are supported too > > class CreateByConstructor { > > final T instance; > > public CreateByConstructor(@GwtCreate final Class fooType) { > instance = GWT.create(fooType); > } > } > > Again, as in Scala implicit parameters, nesting is allowed > > class Foo {} > class SubFoo extends Foo {} > >F createFoo(@GwtCreate final Class fooType) { > return GWT.create(fooType); > } > >S createSubFoo(@GwtCreate final Class subFooType) { > return createFoo(subFooType); > } > > The decision to locate @GwtCreate on parameters was taken to support mixed > code-gen methods > > > void fooBarCreator(@GwtCreate final Class fooType, @GwtCreate final > Class barType) { > foo = GWT.create(fooType); > bar = GWT.create(barType); > } > > Note that the @GwtCreate class parameters aren't replaced by > GwtCreateFactory as was originally suggested by Ray Cromwell. This provides > access to actual parameters. > > Class storedType; > T instance; > > void createFoo(@GwtCreate final Class type) { > storedType = type; > instance = GWT.create(type); > } > > * Further improvements: > > 1) Support for explicit generators > > @GwtCreate(generator = FooGenerator.class) > > We should forbid assignation between parameters that differs in > @GwtCreate signature > > Foo createFoo(@GwtCreate(generator = FooGen.class) final Class extends Foo>) {...} > > // This will fail > Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final > Class fooType) { > return createFoo(fooType); > } > > 2) Multiple parameters for GWT.create() by means of @GwtCreate.Param > >UiBinder createBinder( > @GwtCreate(generator = UiBinGen.class) final Class uiType, > @GwtCreate.Param final Class ownerType) { > > return GWT.create(uiType, ownerType); > } > > @GwtCreate.Params must respect the same kind of signature rules than > @GwtCreate, and a strict order of invocation > > // Good ordering > Foo createFoo( > @GwtCreate final Class fooType, > @GwtCreate.Param final Class arg1, > @GwtCreate.Param final Class arg2) { > return GWT.create(fooType, arg1, arg2); > } > > // Bad ordering, this will fail > Foo createFoo( > @GwtCreate final Class fooType, > @GwtCreate.Param final Class arg1, > @GwtCreate.Param final Class arg2) { > > return GWT.create(fooType, arg2, arg1); > } > > To allow mixed multiple code-gen parameters, we would bind main > parameters by name > > > void mixedMultiple( >