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 02:08:10 -0700
To: Geoffrey Garen <ggaren@apple.com>
Cc: public-webapps@w3.org
Message-id: <23B1B120-2A8E-401A-99B7-BA5ED80E431B@apple.com>

On Oct 3, 2008, at 1:40 AM, Geoffrey Garen wrote:

>>> 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.
> A Timer constructor is language-agnostic as long as you specify that  
> "new Timer()" and "Timer()" behave the same way. Other JavaScript  
> constructor APIs, like Array, behave this way.
> The fact that most things in the DOM aren't instantiated by  
> constructors is really just an accidental consequence of the fact  
> that they're available as properties of the document, and it makes  
> no sense to create them standalone. The two qualities are not found  
> in timers.

There is DOMImplementation.createDocument() instead of 'new Document',  
Document.createElement() instead of new Element(), etc. All of the  
core DOM, and many language-specific DOMs, follow this pattern. Using  
factory functions instead of relying on constructors is a deliberate  
design pattern in the DOM, not an accident, according to the DOM Core  

>> 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.
> That seems like a minor criticism, relative to the pros above.

"fits the object-oriented programming model" seems pretty weak  
compared to readability of the resulting code.

I do think there should be a global Timer object holding the prototype  
as is typical for DOM objects, that is a standard thing in Web IDL so  
I did not spell it out. But I don't think it needs to support  
construct, nor do I think that should be the sole way to start a timer.

> Besides, we all know that if this API becomes standardized, Mozilla  
> is going to add a global Timer constructor, just like they did for  
> all the other classes in the DOM. And we all know that WebKit will  
> follow suit. So why not get a jump start on things, and specify it  
> that way from the beginning?

Most of Mozilla's global "constructors" cannot construct, e.g.  
HTMLElement. Only a selected few (Image, Option, XMLHttpRequest, maybe  
some others) do.

> I guess we could make a Timer constructor that threw when you called  
> it, as we did with node-related DOM constructors, but that behavior  
> is really weird.

I think Web IDL specs that by default though it can be overriden.

Anyway, the fact that starting the timer is not an obvious effect of  
'new Timer()', and the fact that starting it is the primary purpose of  
the method and creating a timer object is just a side effect, makes me  
think startTimer() should be available even if 'new Timer()' happens  
to also work. Keep in mind, in a lot of cases you won't even care  
about storing the result of startTimer() and calling a constructor for  
side effect only, without storing the result, will look weird in code.

Even in C++ it's normal to use a free function or static "named  
constructor" when something a bit more non-obvious than creating and  
initializing an object happens.

Received on Friday, 3 October 2008 09:08:52 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC