- From: Chris Marrin <cmarrin@apple.com>
- Date: Fri, 03 Oct 2008 11:38:36 -0700
- To: Geoffrey Garen <ggaren@apple.com>
- Cc: Maciej Stachowiak <mjs@apple.com>, WebKit-Dev Development <webkit-dev@lists.webkit.org>, public-webapps@w3.org
On Oct 3, 2008, at 11:15 AM, Geoffrey Garen wrote:
> Hi Chris.
>
>> I really like the idea of a Timer object. It would allow you to
>> separate creation from starting, allows you to pause and add other
>> API's to the interface. Can the constructor be used to simplify the
>> creation:
>>
>> var t = new Timer(0, false, function() { ...});
>>
>> which would start the timer immediately, as in your example.
>
> I think Maciej has made a convincing case that "new Timer" is a bit
> too coy about the fact that the timer is actually starting.
>
>> Or you could do:
>>
>> var t = new Timer(function() { ... });
>> ...
>> t.startOneShot(1.76);
>
> I like your suggestion of adding "startOneShot" (and
> "startRepeating"?) to the API. I think it would improve clarity over
> a bool parameter specifying whether the timer repeats.
>
> To create a Timer that isn't scheduled to fire:
>
> new Timer(...)
>
> To create a Timer that is scheduled to fire:
>
> new Timer(...).startOneShot(...)
> new Timer(...).startRepeating(...)
>
> Or, if we don't like constructors:
>
> createTimer(...).startOneShot(...)
> createTimer(...).startRepeating(...)
Yeah, I fully understand the desire to avoid ctors. I hope Maciej can
add a deferred start capability to his proposed timer...
-----
~Chris
cmarrin@apple.com
Received on Friday, 3 October 2008 21:32:32 UTC