A slight tweak to what Ian said: What if we got this effect by simpy
requiring you to use interfaces that extend
AsyncCallback as a way to reify split points?
interface EmailCompositionView extends AsyncCallback {
...
}
Then you definitely have a fully-qualified name for a split point if you
need it: the name of the interface itself. My worry about Ian's proposal is
that method overloading complicate things (would you use JSNI-style refs to
disambiguate?). And my worry with user-assigned names is that actually may
conflict, when you consider that library writers probably will want to ship
libraries with split points. Again, using interfaces guarantees we don't
introduce a new axis of name conflict.
-- Bruce
On Fri, Jun 19, 2009 at 11:44 AM, Ian Petersen <ispet...@gmail.com> wrote:
>
> On Fri, Jun 19, 2009 at 8:33 AM, Lex Spoon<sp...@google.com> wrote:
> > This looks like a straightforward and easily understood way to name
> > calls to runAsync. What do others think?
>
> As a brainstorm-quality idea, what about requiring that runAsync
> invocations are in their own methods (as you mentioned) but not
> requiring an annotation? Any given method already has a fully
> qualified name (it's even globally unique within the program) so why
> introduce yet another name in the annotation?
>
> Some compiler magic to make this happen might be a nice-to-have:
>
> RunAsyncRef ref = new RunAsyncRef(ClassContainingMethod.class,
> "methodName");
>
> You could statically determine that it's valid, use ref as a token to
> refer to fragments as necessary, and avoid having to specify
> package.ClassName.methodName because you take advantage of the import
> statements. Dunno what you'd do with it, of course.
>
> Ian
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
