W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2008

Re: [webkit-dev] Proposed Timer API

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
Message-id: <B7E5DAF8-31AD-4B12-B426-C62341C4A22B@apple.com>

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:28 GMT