In answer to your question, yes, runAsync works, but no, there's no
test case. It would be great if there were, but I don't know how to
fit it into the JUnit infrastructure. It requires testing that an
async event eventually happens.
Can we talk some about the more general design of this
[Redacted summary]
AsyncProxy:
- Less boilerplate code at the call sites and on the thing being async-loaded.
- Centralized error handling while the concrete type is outstanding.
- Better isolation of concrete types from calling environment, to
give CodeSplitter more room to work.
-
Bob,
I had a question about this. Won't this create a separate JS
fragment for each Proxy? It seems like people could use this in
pathological ways, by being too fine-grained. At a certain size, the
benefit of async-loading the Javascript would be washed out by the
network overhead in loading
On Tue, Dec 16, 2008 at 11:15 AM, Lex Spoon sp...@google.com wrote:
My concern is that there were high hopes that the vast majority of
method calls in a program could actually be known-synchronous. The
problem is that for any operation that might happen asynchronously,
the developer needs to
Initial implementation committed at r4347 for more general review with
a desk review of the implementation by Ray. I'll address any
follow-up reviews with a second commit.
Changes from previous patch:
- Added a @DefaultValue annotation to allow @AllowNonVoid getters to
return whatever value
