On 2010-03-04, at 11:13 AM, BobV wrote: > > These factory methods need to live in the Java AST so that we can > use the type tightener to optimize the (usual-case) polymorphic > dispatch. Adding a JHasNameRef node to the AST would allow what > you're describing to be built, but I think that would overly > complicate the initial implementation. > > Generally, the result of a GWT.create() is a service implementation > assigned to a static field, so the cost of the switch is only paid > once. In the case where there's only one answer for a rebound type > across the collapsed permutations, such as an async RPC > implementation, the GWT.create() is replaced with a plain > instantiation expression. Do you have a use case where you're > repeatedly calling GWT.create() for instances of a rebound type?
We use repeated calls to GWT.create() for dependency injection and to generate code for our internal widget templating framework. Both of them also use nested GWT.create() calls under the hood in generated code for instantiating associated resources bundles. The gwt-rpc-plus framework also uses a call to GWT.create() to initialize the appropriate transports for every request. I can rework them to cache the results of GWT.create(), although I don't believe many of them would ever end up with more than one soft permutation always. The code was written under the assumption that the compiler would elide the call to GWT.create() in most cases and replace instance method calls with static ones (which still holds in most cases of course). It probably won't have a great effect on our overall performance even if some of the classes ended up with runtime switches in the output code, since all of those calls aren't in performance-critical code. Type tightening could still be done ahead of time on the return value of the JSNI method, couldn't it? The results of type tightening would always be the tightest common superclass of all of the potential results. AFAICT, this tightened return value should be statically computable from the list of possible rebinds from the soft permutation since each of the types potentially returned is guaranteed to be in the final output code. Matt. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
