Is there any other design criterion that people can see? The main
ones I see are that it's easy to implement and maintain, it's easy to
spec, and that developers can use it without needing any major code
refactor. That narrows it down to either an annotation on the method
(option 1), or an
On Wed, Jun 24, 2009 at 9:32 AM, Lex Spoonsp...@google.com wrote:
It's the *call* of runAsync that the compiler pays direct attention
to, not its argument. That's why I am pushing back against approaches
that annotate some aspect of the argument.
I think the push-back is a really good idea.
On Wed, Jun 24, 2009 at 12:48 PM, Ian Petersenispet...@gmail.com wrote:
The following should be allowed:
@SplitPointName(foo)
final AsyncCallback callback = chooseACallback();
if (flipACoin())
GWT.runAsync(callback);
else
GWT.runAsync(callback);
I don't see how to literally allow
On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoon sp...@google.com wrote:
Overall, unless I missed something, it's down to style and taste. I'd
pick 1, then 4, then 6. Ian has indicated preferring 6, then 4, then
1. I presume Cameron prefers 4 over anything else. Shall we go with
4, then,
On Wed, Jun 24, 2009 at 11:15 AM, Lex Spoonsp...@google.com wrote:
On Wed, Jun 24, 2009 at 12:48 PM, Ian Petersenispet...@gmail.com wrote:
The following should be allowed:
@SplitPointName(foo)
final AsyncCallback callback = chooseACallback();
if (flipACoin())
GWT.runAsync(callback);
On Wed, Jun 24, 2009 at 2:15 PM, Lex Spoonsp...@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
I prefer 4 as well, because I think it will be less prone to error and it is
more directly associated with the runAsync call.
However, I'm curious, what is the effect of the following:
GWT.runAsync(foo, callback1);
GWT.runAsync(bar, callback1);
That would appear to me to generate identical code,
On Wed, Jun 24, 2009 at 5:08 PM, Ray Cromwellcromwell...@gmail.com wrote:
I prefer 4 as well, because I think it will be less prone to error and it is
more directly associated with the runAsync call.
However, I'm curious, what is the effect of the following:
GWT.runAsync(foo, callback1);
On Wed, Jun 24, 2009 at 5:08 PM, Lex Spoon sp...@google.com wrote:
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
On Wed, Jun 24, 2009 at 2:08 PM, Ray Cromwellcromwell...@gmail.com wrote:
However, I'm curious, what is the effect of the following:
GWT.runAsync(foo, callback1);
GWT.runAsync(bar, callback1);
That would appear to me to generate identical code, but with two different
named output files.
I
On Wed, Jun 24, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
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
Each of these different libraries would be enclosed within a unique GWT
module therefore when you refer to the split point name, can't you just use
the module name + split point name ?
in module ThirdParty :
GWT.runAsync(one, new RunAsyncCallback() { ... });
in MyModule :
GWT.runAsync(one, new
Four additional arguments in favor of using split point moniker classes is
that they
1) are easier to find within an IDE (i.e. Show References in your IDE from
a moniker class declaration would show you the associated runAsync call),
2) can take advantage of inheritance as a way to group split
All good points.
Would interfaces be supported as well ?
Are there any dangers of allowing arbitrary classes (or interfaces) to be
used as monikers ?
i.e from your example, would there be anything wrong with using
EmailCompositionView.class as the moniker ?
void onComposeButtonClicked() {
I guess the compiler would have to verify that each call to runAsync uses a
unique moniker - is there anything else ?
I think that's it. Pretty easy to check, and pretty easy for a developer to
reason about, too.
Must the moniker class exists in your own module ?
I don't think it ought to
For what it's worth, I like the moniker class idea best. Staying type
safe, IMHO, is always a good thing.
With regards to the downside John Tamplin mentioned (multiple runAsync
calls in one class), why not consider that a feature? Since the
original idea of naming the runAsync call is to allow
On Mon, Jun 22, 2009 at 7:33 PM, Ian Petersenispet...@gmail.com wrote:
Here's what I mean:
// ... surrounding code ...
GWT.runAsync(new AsyncCallback() {
public void onFailure(Throwable caught) {
// deal with failure
}
@SplitPointName(I like Bruce's idea)
Okay, we now have a suite of options. Does anyone see any
particularly strong reason to pick among them?
The options I see are:
1. Annotate the surrounding method with something like @RunAsyncName(Foo)
2. Use the fully-qualified method name surrounding the call.
3. Use the fully-qualified type
Great writeup. Thanks for bringing some organization to the thread. I agree
with you that #1 seems overall best after the analysis.
Now can we bikeshed about the annotation name? @RunAsyncName() seems harder
to understand than something that says code splitting, such as
@SplitPointName(Foo). After
On Mon, Jun 22, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
The options I see are:
1. Annotate the surrounding method with something like @RunAsyncName(Foo)
2. Use the fully-qualified method name surrounding the call.
3. Use the fully-qualified type name of the callback object.
4. Use
+1 Ian! Great point. Not sure why we didn't think of that before.
On Monday, June 22, 2009, Ian Petersen ispet...@gmail.com wrote:
On Mon, Jun 22, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
The options I see are:
1. Annotate the surrounding method with something like
On Fri, Jun 19, 2009 at 8:33 AM, Lex Spoonsp...@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
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
On Fri, Jun 19, 2009 at 9:57 AM, Bruce Johnsonbr...@google.com wrote:
My worry about Ian's proposal is
that method overloading complicate things
Excellent point--wasn't thinking about overloads. I think your
solution might be more elegant--it seems easier to explain,
understand, and enforce
I've been working to improve load behavior of a very large application with
a few dozen
runAsync calls, and for Javadoc clarity I've been putting each call in
its own method
anyway -- found this very useful to track the purpose and timing of each
split, and document any known implications. So in
You could always change the signiture of GWT.runAsync to include a String
parameter as the first parameter. I must be a literal in code, and would be
optimized out / ignored by the compiler :
GWT.runAsync(foo, new RunAsyncCallback() {
Cam
2009/6/20 Lex Spoon sp...@google.com
There are
26 matches
Mail list logo
