Just to flush out my dissention a little more, I don't see what
re-architecting it is going to do for the user experience, and I know
it is going to cause at least as much pain as benefit for the
developer experience.
I love writing shiny new APIs too, but going with the minimal screwing
with the API approach, you could just make a new
DeferredCommand.addBatchedCommand(Command cmd) and get this new
functionality and be done with it.
1) The new dispatch-my-command-before-the-event-loop may be important
for the Css injection case, but I haven't seen any suggestion that its
going to be used for anything other than that - an important, but very
infrequently used feature.
2) If you want to make a new testable deferred/incremental command
class, fine, you can do that, but I don't think it requires yet
another round of deprecating deferred command stuff - you can write it
on top. Again, most developers aren't going to be mocking out and
overriding timers for their test cases, yet the implication is that
all developers need this (they don't)
3) Look at what will happen to the API after the suggested round of
deprecations. There will be more ways NOT to do something than the
recommended way to actually get work done. And pedantic arguments
aside, it will be yet another collection of custom class names where
we could have used 'Runnable' and 'Callable' that java developers are
already familiar with.
All I'm asking is for us to think about, "Is a shiny new API it really
worth the ugliness for developers? Do users get something significant
in return for developer pain?"
Signed,
A developer
On Fri, Sep 4, 2009 at 11:36 PM, Eric Ayers<zun...@google.com> wrote:
> -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 tutorial and blog post already written that tells
> you how to do fun stuff in GWT with these tools.
>
> On Fri, Sep 4, 2009 at 11:00 PM, Miroslav
> Pokorny<miroslav.poko...@gmail.com> wrote:
>>
>> Slightly off topic more of a design comment.
>>
>> For me Job would be a better name than Command. Command reminds me of
>> the command pattern while job is always a background task that might
>> execute sooner or later.
>>
>> It also seems like there are lots of "duplicate" add methods for lack
>> of a better of description, whereby each type of Command has it's own.
>> What about a central manager type class with a single add( Job,
>> JobType) where JobType is Incremental, Timed, etc.
>>
>> For the Timed version there would be factory to pass the when or how
>> often etc, or as in the previous email from Bruce AsapJob.
>>
>> I can also see a benefit of allowing developers to change the command
>> (job) type by changing the JobType parameter which seems simpler /
>> more flexible than the hard coded static adds and super type.
>>
>> Just an idea...
>>
>> On 05/09/2009, at 4:35 AM, Ray Ryan <rj...@google.com> wrote:
>>
>>> 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}
>>> */
>>> boolean execute();
>>> }
>>>
>>> That's a bit redundant with the TimerController--would it even be
>>> honored by TimedCommands?
>>>
>>> Let me propose this (actually, I think steal it from Brian Brian
>>> Slesinsky) , to allow every command to reschedule itself or not.
>>>
>>> rjrjr
>>>
>>> interface Command {
>>> /**
>>> * @param dispatcher To allow this command to requeue
>>> * itself, or add other commands. Presto, it's
>>> * all three of timed, incremental and one off
>>> */
>>> void execute(CommandDispatcher dispatcher);
>>> }
>>>
>>> interface CommandDispatcher {
>>> enum When {
>>> FINALLY,
>>> ASAP
>>> }
>>>
>>> public static CommandDispatcher get();
>>>
>>> public void add(Command c);
>>>
>>> public void add(Command c, When w);
>>>
>>> public void addDeferred(Command c, int millis);
>>> }
>>>
>>> That's the whole thing. For convenience, we could also offer stuff
>>> like the following. Perhaps
>>> // better to see what evolves
>>>
>>> abstract class IncrementalCommand implements Command {
>>> public void execute(CommandDispatcher dispatcher) {
>>> if (doExecute()) {
>>> dispatcher.add(this);
>>> }
>>> }
>>>
>>> /** @return true to keep going */
>>> abstract boolean doExecute();
>>> }
>>>
>>> and
>>>
>>> public class TimedCommand implements Command {
>>> private final wrappedCommand;
>>> private final interval millis;
>>> private boolean stopped;
>>>
>>> public TimedCommand(int millis, Command wrappedCommand) {
>>> this.wrappedCommand = wrappedCommand;
>>> this.millis = millis;
>>> }
>>>
>>> public void stop() {
>>> stopped = true;
>>> }
>>>
>>> public void execute(CommandDispatcher dispatcher) {
>>> if (!stopped) {
>>> wrappedCommand.execute(dispatcher);
>>> dispatcher.add(this, millis);
>>> }
>>> }
>>> }
>>>
>>>
>>> >
>>
>> >>
>>
>
>
>
> --
> Google Code Jam 2009
> http://code.google.com/codejam
>
--
Google Code Jam 2009
http://code.google.com/codejam
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
