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 try/catch that then invoke exactly the same code path
that the uncaught exception handler would've called anyway.
2) Callable is closer, but it has a close association with the Executor
family, which itself has lots of connotations, most of which we can't honor.
3) I see the spritual similarity to ExecutorService/Future, but I don't see
that there's any proper subset we could implement that would cover the same
use cases. Even if we could, the standard Java for that subset could be
misleading relative to the semantics we are trying to guarantee -- that is,
we'd like to say stuff like "runs at the next opporuntity after the event
loop has been processed at least once" in the GWT javadoc, otherwise it
comes across as way too abstract.
Perhaps an approach would be to try to perfect the API without trying to
reconcile it, then see if we can map it onto the existing JRE without losing
anything vital.
On Thu, Sep 3, 2009 at 11:21 PM, Ray Cromwell <cromwell...@gmail.com> wrote:
>
> Is there a reason why we just don't add Runnable and Callable<V> 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
> animations).
> -Ray
>
>
> On Thu, Sep 3, 2009 at 7:08 PM, Bruce Johnson <br...@google.com> wrote:
>
>> 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); // asap = faster than
>> setTimeout(0)
>> public void addPause();
>> }
>>
>> // "Finally command" = before you end the current stack trace
>> interface FinallyCommands {
>> public static FinallyCommands get();
>>
>> public void add(Command cmd);
>> }
>>
>> // "Incremental command" = call repeatedly quickly to avoid SSWs
>> interface IncrementalCommands {
>> public static IncrementalCommands get();
>>
>> public void add(Command cmd);
>> public void add(Command cmd, boolean asap);
>> }
>>
>> // "Timed command" = call based clock time (aka regular old timers)
>> interface TimedCommands {
>> public static TimedCommand get();
>>
>> public TimerController scheduleOnce(Command cmd, int millis);
>> public TimerController scheduleRecurring(Command cmd, int millis);
>> }
>>
>> // Allows optional control over a timer after it's created.
>> // If the return values in scheduleOnce, etc. aren't used, extra code can
>> maybe optimize away.
>> interface TimerController {
>> public void pause();
>> public void resume();
>> public void cancel();
>> }
>>
>> I think that maybe consolidating timers into this mix might be a bit much,
>> but, then again, if we're graduating "Command" to core, then it seems like
>> it would be nice to make it the uniform callback interface.
>>
>> -- Bruce
>>
>> On Thu, Sep 3, 2009 at 9:28 PM, Bruce Johnson <br...@google.com> wrote:
>>
>>> 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 re-entrantly. Those names sound like a very strong guarantee
>>> that I don't think we can reliably guarantee. It's more like
>>> "PreCurrentJavaScriptStackFullyUnwinding" and "PostEventLoop".
>>>
>>> Actually, to take a step back (which is my very favorite thing to do),
>>> there are several kinds of things that could be consolidated:
>>>
>>> 1) Single-shot timers
>>> 2) Recurring timers
>>> 3) Incremental commands that run as soon as possible after the event loop
>>> (faster than setTimeout(0))
>>> 4) Incremental commands that run after the event loop via setTimeout(0)
>>> 5) Deferred commands that run as soon as possible after the event loop
>>> (faster than setTimeout(0))
>>> 6) Deferred commands that run after the event loop via setTimeout(0)
>>> 7) Execute-this-before-you-unwind-the-JS-stack-in-which-it-was-enqueued
>>> (aka BatchedCommand)
>>> 8) Arguably, runAsync (although it's purpose is so functionally different
>>> it would probalby be a mistake to munge it in)
>>>
>>> #3 and #5 might look funny, but it is generally possible to run code
>>> *after* the event loop but *much* sooner than setTimeout(0), which is
>>> usually clamped to some pretty long duration such as 10ms. The reason you
>>> wouldn't want to do #3 and #5 as the default for deferred commands is that
>>> it would keep the CPU overly busy if you did it a bunch in a row. It would
>>> very likely drain mobile batteries quickly, even.
>>>
>>> @Ray (or anyone): Can you think of an awesome way to reconcile those
>>> behind a consistent API?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Sep 3, 2009 at 4:52 PM, Joel Webber <j...@google.com> wrote:
>>>
>>>> ++(++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 matter for small apps), that would be even better.
>>>>
>>>>
>>>> On Thu, Sep 3, 2009 at 4:46 PM, Scott Blum <sco...@google.com> wrote:
>>>>
>>>>> ++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 with a different name, and you have to subclass it
>>>>>> rather than implement it...
>>>>>>
>>>>>> A simple thing we could do is:
>>>>>>
>>>>>> - create com.google.gwt.core.client,
>>>>>> - change com.google.gwt.user.client.Command to extend the new one
>>>>>> - deprecate com.google.gwt.user.client.Command
>>>>>> - And have BatchedCommand accept com.google.gwt.core.client
>>>>>>
>>>>>> And the two names, "DeferredComand" and "BatchedCommand", don't give
>>>>>> much clue as to which does what. And of course BatchedCommand doesn't
>>>>>> actually provide any batching service.
>>>>>>
>>>>>> If we were doing all this from scratch, I suspect we would wind up
>>>>>> with something like this in core (presuming we're happy with
>>>>>> IncrementalCommand and addPause):
>>>>>>
>>>>>> package com.google.gwt.core.dispatch
>>>>>>
>>>>>> public interface Command {
>>>>>> void execute();
>>>>>> }
>>>>>>
>>>>>> public interface IncrementalCommand {
>>>>>> boolean execute();
>>>>>> }
>>>>>>
>>>>>> public class PreEventLoopDispatcher {
>>>>>> public static PreEventLoopDispatcher get(); { ... }
>>>>>>
>>>>>> public void addCommand(Command c);
>>>>>> }
>>>>>>
>>>>>> public class PostEventLoopDispatcher {
>>>>>> public static PostEventLoopDispatcher get(); { ... }
>>>>>>
>>>>>> public void addCommand(Command c);
>>>>>> public void addCommand(IncrementalCommand c);
>>>>>> public void addPause();
>>>>>> }
>>>>>>
>>>>>> Note the avoidance of statics to make commands more testable, a
>>>>>> recurring subject.
>>>>>>
>>>>>> Seems like we could do this, deprecate the existing classes, and make
>>>>>> them wrappers around the new.
>>>>>>
>>>>>> </bikeshed>
>>>>>>
>>>>>> On Wed, Sep 2, 2009 at 11:36 PM, Ray Cromwell
>>>>>> <cromwell...@gmail.com>wrote:
>>>>>>
>>>>>>>
>>>>>>> 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. But this rather breaks the nice OO design people are used to with
>>>>>>> widgets. Templating is an alternative, but I'm wondering, why can't we
>>>>>>> make
>>>>>>> all of the attachment stuff happen via a batch queue. A special
>>>>>>> optimizer on
>>>>>>> the queue could even recognize instances of when DOM updates can be
>>>>>>> coalesced and leverage documentFragment or innerHTML.
>>>>>>> e.g.
>>>>>>>
>>>>>>> VerticalPanel vp = ...
>>>>>>> vp.add(new Label())
>>>>>>> vp.add(new Label())
>>>>>>>
>>>>>>> The objects are constructed, but the HTML mutations are
>>>>>>> deferred/queued. When adding a DOM mutation to the queue, you could
>>>>>>> check if
>>>>>>> existing queue data isOrHasChild the new DOM mutation element, and if
>>>>>>> so,
>>>>>>> just modify the queue element (coalesce) rather than appending another
>>>>>>> queue
>>>>>>> item. Then, when processing the queue, you only need to add the roots
>>>>>>> to the
>>>>>>> DOM, attaching/modifying enmasse.
>>>>>>>
>>>>>>> This would preserve the OO-ness of constructing widget hierarchies
>>>>>>> without requiring 'foreign' string-based templating.
>>>>>>>
>>>>>>> -Ray
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Sep 2, 2009 at 5:13 PM, Bruce Johnson <br...@google.com>wrote:
>>>>>>>
>>>>>>>> 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 and modify all our
>>>>>>>>> event code
>>>>>>>>> (like with the global uncaught exception handler)?
>>>>>>>>
>>>>>>>>
>>>>>>>> No trick, it's as bad as you'd hope it wasn't. On the positive side,
>>>>>>>> it's already been done -- I'm just augmenting the tests for the various
>>>>>>>> subsystems such as RequestBuilder and event dispatching to make sure we
>>>>>>>> tighten the correctness noose as much as possible.
>>>>>>>>
>>>>>>>> Longer term, Bob and I both would really like to find a general
>>>>>>>> mechanism for making this pattern easy to do from any path into a GWT
>>>>>>>> module
>>>>>>>> from "the outside", exactly along the lines of what Matt was talking
>>>>>>>> about.
>>>>>>>> I think rolling this functionality into gwt-exporter (and then rolling
>>>>>>>> that
>>>>>>>> sort of functionality directly into GWT proper) will get us pretty far
>>>>>>>> down
>>>>>>>> the road.
>>>>>>>>
>>>>>>>> Code review request forthcoming, possibly tomorrow.
>>>>>>>>
>>>>>>>> -- Bruce
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
