- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 6 Mar 2006 10:52:46 -0800
- To: Ian Davis <Ian.Davis@talis.com>
- Cc: public-webapi@w3.org
- Message-Id: <7E27F731-B835-46E0-805A-EF28D78FA54C@apple.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. Regards, Maciej
Received on Monday, 6 March 2006 18:53:07 UTC