W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

Re: Timers in window interface

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 6 Mar 2006 10:52:46 -0800
Message-Id: <7E27F731-B835-46E0-805A-EF28D78FA54C@apple.com>
Cc: public-webapi@w3.org
To: Ian Davis <Ian.Davis@talis.com>

On Mar 6, 2006, at 9:03 AM, Ian Davis wrote:

> Maciej's initial draft [1] introduces a new TimerListener interface  
> that is passed to the setTimeout and setInterval methods. This  
> seems like a break to existing behaviour which is to pass a  
> function or a string to be eval'ed. There has been some discussion  
> on the lists about this design but no clear consensus. Clearly it's  
> a goal to rationalise the window interface so that it fully  
> supports DOM events but we also need to document existing behaviour.
> My proposal is to keep setInterval/setTimer in their two argument  
> function forms, i.e. they expect a function as first argument and a  
> delay in milliseconds for the second. The parameter list form has  
> been shown to be non-interoperable [2]. We don't endorse support  
> for the string eval form.
> We then define new events for the interval and timer - although I'm  
> not sure about the mechanics at this stage. Should it be  
> setIntervalListener?
My intent was doing this was that ECMAScript bindings would define a  
special rule so that only functions or strings are actually accepted,  
much the way functions are accepted by EventTarget.addEventListener.  
The reason for this is that the "function or string" interface  
doesn't really work for non-ECMAScript languages. In particular, for  
Java, "eva this string" is not a sensible interface.

Received on Monday, 6 March 2006 18:53:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC