The most important issue in my mind is that it isn't always
appreciated to take a minor feature change that very few developers
will ever use and use it as an excuse to mix up the existing API.
Take, in contrast, the xxxListener to xxxHandler change. There was a
lot of pain in that one, but it
As a long time Java programmer (since v0.9!), I'd just like to throw
in that I don't see any particular practical benefit to leveraging
Runnable or CallableV. Sure, they are just interfaces, and you
could re-use them. But beyond that, especially with respect to
CallableV, almost nothing
I'm definitely not a Java pedant, so maybe there's something
wrong/underinformed with my perspective here, but here's my take...
1) Why Runnable isn't quite right
- Has close associations with threads
- Isn't spec'd to throw Throwable, which means what could be simple callbaks
have to always have
I like the Finally name.
Since you have a single Command object used by Incremental along with
everyone else, you're implying interface
Command {
/**
* @return whether this command should be run again.
* Checked only by {...@link IncrementalCommands} and {...@link TimedCommands}
*/
Because the dispatcher methods are not static you can write your code to
have the dispatcher injected, and at test time provide whatever alternative
implementation you want. So long as you don't use the static get method
outside of your Gin module or whatever, you're golden.
Not good enough?
On
-1 for renaming and deprecating the DeferredCommand, etc calls unless
there is really something significant other than the name change. As
a maintainer, I get sick of APIs moving around underneath my code and
having someone else tell me its broken. Furthermore, you'll make
obsolete every good
Could this also be used as a general pattern to batch DOM updates from
multiple Widgets performing updates? e.g. a current approach to avoid the
overhead, of say, installing a dozen widgets, is to concatenate all the HTML
together, slam it into innerHTML, and then wrap the widgets around the HTML.
The mechanism is just brilliant. I have reservations about the api.
bikeshed
it seemed kinda nice to have one less type
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except with a different name, and you have to subclass it rather
than implement it...
A
++Ray.
On Thu, Sep 3, 2009 at 4:38 PM, Ray Ryan rj...@google.com wrote:
The mechanism is just brilliant. I have reservations about the api.
bikeshed
it seemed kinda nice to have one less type
Except that we have one more type, BatchedCommand, which looks exactly like
Command, except
++(++Ray)
Anything we can do to sensibly get this crap out of .user and into .core (or
some other common location) would be very, very good.
If, as a side-effect, we could get DeferredCommand to *not* use
IncrementalCommand (the latter brings in fairly significant dependencies
that are enough to
I like it a lot Ray. (To be completely honest, I knew you were going to say
all that, so I decided to sandbag and let you do the typing :-)
I question if it's really appropriate to explicitly say PreEventLoop and
PostEventLoop considering that...sometimes...the event loop can actually
run
Okay, here's a strawman for a new-and-improved proposal. All these would be
in core.
// Deferred command = on the other side of the event loop
interface DeferredCommands {
public static DeferredCommands get();
public void add(Command cmd);
public void add(Command cmd, boolean asap); //
Is there a reason why we just don't add Runnable and CallableV to the JRE
emul and use those instead of Command? This design seems to parallel some of
the patterns in ExecutorService. I could see some of those patterns being
useful (like completion queues, which would be useful for staged
Generally speaking I like the idea. I do agree with John that we should
really discuss how this can be implemented. Is there some magic trick to
make the browser execute a piece of code at the time you want, or do we need
to go and modify all our event code (like with the global uncaught
On Wed, Sep 2, 2009 at 6:07 PM, Scott Blum sco...@google.com wrote:
I do agree with John that we should really discuss how this can be
implemented.
It's already implemented!
Is there some magic trick to make the browser execute a piece of code at
the time you want, or do we need to go
15 matches
Mail list logo
