Re: [webkit-dev] Proposed Timer API

2008-10-03 Thread Maciej Stachowiak



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(...)


It would be pretty unusual for a method like startOneShot or  
startRepeating to return a value. I'm not sure if you indended that;  
if not



Or, if we don't like constructors:

createTimer(...).startOneShot(...)
createTimer(...).startRepeating(...)


We could rename the restart() method to start() (with the same  
semantics, or also taking a bool) and have both createTimer() and  
startTimer() if we think this use case is very important. I don't  
think the need for unstarted timers is very high. However, here's yet  
another tricksy way to achieve the same thing:


var tSpec = [0, false, function() {...});
...
var t = startTimer.apply(window, tSpec);

I think setting up a Timer with the intent of not only starting it but  
defining the timing parameters is extra useless, since then all it  
represents is a function.


Regards,
Maciej





And you could easily add animation or media API's for  
synchronization:


   var t = new Timer(1.76, function() { ... }); // when the timer is
triggered, it will run for 1.76 seconds
   var transition = window.getTransitionForElement(element, left);
   transition.trigger(t);
   ...
   element.style.left = 100px;

This would cause the timer to start when the left transition starts
and fire its event 1.76 seconds later.


This would be really cool!

Geoff





Re: [webkit-dev] Proposed Timer API

2008-10-03 Thread Chris Marrin


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
[EMAIL PROTECTED]