On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon<sp...@google.com> wrote:
> Overall, unless I missed something,
Okay, Bruce pointed out a new constraint to me: if different libraries
name their runAsync calls, then we want to able to refer to those
calls reliably even if different libraries choose the same name. This
isn't an issue immediately, but it likely will be in the future.
Thinking about libraries, I would add another constraint: we don't
want libraries to have to expose their implementation. Library
writers should ideally be able to document a named runAsync call
without exposing the precise arrangement of their internal classes.
After some discussion at the office, a tweak to option 4 fixes things
up handily. Instead of passing in a string to the method, act like a
Java framework and require passing in a class literal. A typical use
in application code would pass in the enclosing top-level class:
package org.foodity.impl;
class Cookies {
...
GWT.runAsync(Cookies.class, new RunAsyncCallback() { ... });
...
}
A library writer could instead specify a public class, so as not to
expose their internal factoring.
A user of the name in a gwt.xml file would use the fully qualified version:
<extend-configuration-property
name="compiler.splitpoint.initial.sequence"
value="org.foodity.impl.Cookies" />
A user in another Java file would use imports to make the name short:
import org.foodity.impl.Cookies;
RunAsyncQueue.startPrefetching(Cookies.class);
Thoughts? The main downside I know of is the one John Tamplin has
pointed out: if there are multiple runAsync calls within a single
class -- as sometimes happens -- then the programmer has to code up
some new classes that will only be used for naming. Can we live with
that?
Lex
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
