Heh, I think I always have an opinion on Timers :-) I think Timers should allow 0ms delays and I think we should also have a mechanism for what is commonly called invokeLater. Here's why:
Timers should accept 0ms I do think allowing 0ms is kind of wrong because browsers clamp at 10ms-15ms and browser makers are always flirting with the idea of lowering the clamps and occasionally something like Chrome shows up and actually does lower the clamp. Suddenly that app that used to get called back every 10ms is getting called back every 4ms and it's killing batteries on laptops and making my G5 fan spin up in a fury. But even if the developer had specified 1ms, it still would've killed my batteries and given my G5 a workout. With the current set of browsers, 0ms is no different from 1ms, 2ms...10ms. So if we were going to make a stand and say 0ms is bad practice, we should've made our stand stronger and not allowed any of the lower numbers. But allowing 1ms and not 0ms just makes people ask why we don't support this thing that is clearly common practice in the browser. We should have an invokeLater: We actually have it, it's called DeferredCommand. Unfortunately, we let its implementation get too gangled up with another feature called IncrementalCommand and use of DeferredCommand now generates way too much code. Many developers still use DeferredCommand when wanting to invokeLater. After 1.4, I've seen many people avoid DeferredCommands (including myself) in favor of a very simple method wrapping setTimeout around a GWT Command. (I usually call my postCommand(Command)). So people are interested in the semantics of invokeLater apart from Timers, but we may've blocked the primary way to do that in GWT. I think we should lighten DeferredCommand so it can continue to be our invokeLater. /kel On Mon, Jan 12, 2009 at 12:24 PM, Lex Spoon <sp...@google.com> wrote: > I'd like to revive this thread from last month and argue for a different > spec: > > > http://groups.google.com/group/Google-Web-Toolkit-Contributors/browse_thread/thread/99a70af45e06ed3d?pli=1 > > The question there was what a GWT Timer should do with a timeout of 0, > which is currently prohibited. The thinking there was to mimick what > window.setTimeout does and use the minimum delay. However, I agree > with this post by Eugene Lazutkin: > > http://lazutkin.com/blog/2008/mar/23/javascript-edp-and-0ms-timeouts/ > > There is a lot of good use for having a mechanism for specifying a > callback that you want to run at the top of the event loop. Eugene > argues that this is established practice for all kinds of very popular > GUI toolkits. I would add that it's showing up in language designs > like Erlang and E. This is a powerful tool for apps that are > architected around an event queue. > > We can provide this facility, even though window.setTimeout doesn't do > what is necessary. Here's a question, though: should the > functionality be provided in a new class, or would it be okay to make > Timer do it if the timeout is set to 0? Updating Timer looks cleanest > to me.. However, it will occasionally trip up someone very > knowledgeable about browsers. Such a person might out-clever > themselves by trying to use 0 to mean the minimum delay. > > Opinions? > > -Lex > -- If you received this communication by mistake, you are entitled to one free ice cream cone on me. Simply print out this email including all relevant SMTP headers and present them at my desk to claim your creamy treat. We'll have a laugh at my emailing incompetence, and play a game of ping pong. (offer may not be valid in all States). --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
