Re: Timers in window interface

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

Personally, I wouldn't mind seing support for passing a string to 
setTimeout deprecated. Unless someone has a good usecase of course.

If we really do want to allow a string to be passed then I like the 
approach of defining special ECMAScript bindings to handle it.

/ Jonas

Received on Tuesday, 7 March 2006 08:41:26 UTC