Very cool mechanism, especially if mypackage.compiletime.FormatterEval.class is allowed to determine *by itself* whether to precompile an expression or to use the fallback.
Bart Guijt E: [email protected] T: +31 6 30408987 On 14 feb 2010, at 14 feb, 01:17, Ray Cromwell wrote: > BTW, Scott proposed an even more general mechanism, the idea that you > could designate any expression and having to be done at compile time. > A classic example would be something like String.format(), for example > > public class Formatter { > @CompileTime(mypackage.compiletime.FormatterEval.class) > public String format(String pattern, String... args) { > // case where all parameters are NOT known at compile time > } > } > > In this case,if all parameters are guaranteed to be literals or known > as constants at compile time, then the FormatterEval class will be > invoked which returns a literal value which is inlined at the > callsite. If all types are not known as constant literals, the > fallback body is used. > > > -Ray > > On Sat, Feb 13, 2010 at 3:30 PM, Ray Ryan <[email protected]> wrote: >> 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 > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
