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

Re: Proposal: High resolution (and otherwise improved) timer API

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 03 Oct 2008 00:55:07 -0700
To: Geoffrey Garen <ggaren@apple.com>
Cc: public-webapps@w3.org
Message-id: <E0894F4D-A1D8-4E91-9CC2-A4232C5BDF71@apple.com>

On Oct 3, 2008, at 12:03 AM, Geoffrey Garen wrote:

>> // should be implemented by Window objects
>> interface WindowTimer {
>>      Timer startTimer(in double delayInSeconds, in boolean repeating,
>> in TimerHandler handler);
>> }
>
> How about a "Timer" constructor function instead?
>
> Pros:
>
> * Fits the object-oriented programming model of "new Image", "new  
> XMLHttpRequest", etc.
>
> * Enables use of object-oriented features like instanceof,  
> the .constructor property, and prototype-based extensions to timer  
> objects.
>
> * Distinguishes itself better from the old setTimeout / setInterval  
> functions.

In general, the DOM does not depend on a constructor as the only way  
to create a kind of object, since it is nominally language-agnostic.  
In fact, for most things it doesn't provide a constructor invokable as  
such at all; you listed some of the few exceptions.

In addition, "new Timer(...)" does not as clearly express the fact  
that the timer is not only created but started right away. So I don't  
think a constructor would be good as the sole interface for starting a  
timer.

>> readonly attribute double timeElapsed; // time in seconds since
> "elapsedTime" reads better to me, since it makes "elapsed"  
> definitely an adjective, and not a verb.

Good suggestion.

Regards,
Maciej
Received on Friday, 3 October 2008 07:55:49 GMT

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