If you wanted to be guaranteed order-of-operations safety, you could
pass a factory into the method instead of the object itself and
replace the GWT.create() calls with a create() method on the factory.
AFAICT, this would have the same sequence of side-effects as
GWT.create() would.
Bonus feature: In the case where only one class constant is ever
passed into this method, the compiler should be able to replace the
virtual call with the new MyService() expression (and possibly inline
the whole @GwtCreate function as well).
For instance, something like the following pseudocode:
interface GwtCreateFactory {
<T> T create();
}
class MyService__GwtCreateFactory implements GwtCreateFactory {
@SuppressWarnings("unchecked")
<T> T create() {
return (T)new MyService();
}
}
public class OAuth {
@GwtCreate // method must be static, class parameter must be final
public static <S, T extends RemoteService<S>> S withSignature(final
GwtCreateFactory<T> service) {
// GWT.create with non-literal ONLY allowed
// if enclosing method is @GwtCreate and
// variable statically resolvable to literal param
S async = service.create();
((ServiceDefTarget)async).setRequestBuilderCallback(new
OAuthRequestBuilderSigner());
return async;
}
}
OAuth.withSignature(new MyService__GwtCreateFactory()).method1(arg1,
arg2,
asyncCallback);
On 13-Mar-09, at 12:09 AM, Ray Cromwell wrote:
>
> One concern I have is order of operations, since the GWT.create() is
> implicitly hoisted from its callsite, and I could see some crazy thing
> where code in the method depends on the deferred binding not being
> initialized early. It's kinda like the clinit() hoisting problem. I
> say we just define some rules that allow hoisting within a method
> body, otherwise, you'll have to inline the whole method at the
> callsite (yuck!)
>
> -Ray
>
>
> On Thu, Mar 12, 2009 at 10:55 PM, Matt Mastracci <[email protected]
> > wrote:
>>
>> +1 for this implementation.
>>
>> This is a lot clearer than a class -> implementation lookup map or
>> inlining the whole method at each call site. As long as the bytecode
>> is rewritten in hosted mode to match the expected order of
>> operations,
>> there shouldn't be any surprises at compile time.
>>
>> Could this cause issues with anyone running GWT.create() in server-
>> side code? Does that even work today?
>>
>> On 12-Mar-09, at 10:23 PM, Ray Cromwell wrote:
>>
>>>
>>> BTW,
>>> My proposed implementation is to rewrite these methods changing the
>>> literal parameter to the result of invoking GWT.create() at the call
>>> site, e.g.
>>>
>>> interface MyService extends RemoteService<MyServiceAsync> { ... }
>>> // example call
>>> OAuth.withSignature(MyService.class).method1(arg1, arg2,
>>> asyncCallback);
>>>
>>> public class OAuth {
>>> @GwtCreate // method must be static, class parameter must be final
>>> public static <S, T extends RemoteService<S>> S withSignature(final
>>> Class<T> service) {
>>> // GWT.create with non-literal ONLY allowed
>>> // if enclosing method is @GwtCreate and
>>> // variable statically resolvable to literal param
>>> S async = GWT.create(service);
>>> ((ServiceDefTarget)async).setRequestBuilderCallback(new
>>> OAuthRequestBuilderSigner());
>>> return async;
>>> }
>>> }
>>>
>>> after rewrite at callsite:
>>> Object async = GWT.create(MyService.class);
>>> OAuth.withSignature(async).method1(arg1, arg2, asyncCallback);
>>>
>>> rewritten method:
>>> public class OAuth {
>>> @GwtCreate // method must be static, class parameter must be final
>>> public static <S, T extends RemoteService<S>> S
>>> withSignature(Object
>>> asyncInstance) {
>>>
>>> //S async = GWT.create(service); replaced with instance
>>> S async = (S)asyncInstance;
>>> ((ServiceDefTarget)async).setRequestBuilderCallback(new
>>> OAuthRequestBuilderSigner());
>>> return async;
>>> }
>>> }
>>>
>>> This doesn't handle generator override or extra params, but it's a
>>> start and could work with minimal changes to ReplaceRebinds.
>>>
>>> -Ray
>>>
>>> On Thu, Mar 12, 2009 at 7:17 PM, Ray Cromwell
>>> <[email protected]> wrote:
>>>> Yeah, it's mostly the same as was discussed in the past. I just
>>>> decided to resurrect the idea given that 1.6 is almost shipped to
>>>> ensure it has a good chance of making it into the next version.
>>>>
>>>> -Ray
>>>>
>>>> On Thu, Mar 12, 2009 at 5:49 PM, Ian Petersen <[email protected]>
>>>> wrote:
>>>>>
>>>>> Seems like this might be related to
>>>>> http://code.google.com/p/google-web-toolkit/issues/detail?id=2243
>>>>>
>>>>> I like the idea.
>>>>>
>>>>> Ian
>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>>
>>
>>
>>>
>>
>
> >
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
