[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(
>
