RE: ISSUE-7: FrameRequestCallback interface should be designated as Callback=FunctionOnly [Request Animation Frame]

There's a bit of a duality between wanting to be consistent with setTimeout and/or DOM Events. For instance, in another thread, we decided to allow duplicate callbacks to be registered since that would be consistent with what setTimeout does and help drive adoption of this API. However, that is inconsistent with DOM Events which don't allow duplicate callback registration.

In this case, there is a desire to be consistent with DOM Events in how the callbacks can be defined. But we can note that setTimeout doesn't support object callbacks so web developers are keeping track of state for their animation-step functions by some other means today.

Here, my main concern is that we would be expanding the API surface area without a demonstrated need for doing so (as Cameron suggests, one can keep track of callback state using Function objects/closures). Having a clear rationale for supporting object callbacks (other than consistency, since we're being inconsistent in other ways as mentioned above) or some data around the usage of object callbacks or a demonstrable use-case would be helpful.

Savil
p.s. I'll readily concede that I'm not familiar with the history behind why DOM Events do support object callbacks -- I suspect it might have to do with a desire to support languages that do not support closures (e.g. C++/COM), and I'm not aware of whether that is a goal for this (RAF) API too, but again this is just speculation. 

________________________________________
From: Cameron McCormack [cam@mcc.id.au]
Sent: Wednesday, June 01, 2011 4:17 PM
To: pettay@mappi.helsinki.fi
Cc: Savil Srivastava; Web Performance Working Group WG
Subject: Re: ISSUE-7: FrameRequestCallback interface should be designated as Callback=FunctionOnly [Request Animation Frame]

Olli Pettay:
> Is there any reason to not allow objects?
>
> DOM Events happen to be one of the most commonly used
> interfaces using callbacks. For consistency callbacks should work
> the same way.
> (if they don't in geolocation, that could be a bug in that draft.
>  geolocation is a bit strange API anyway.)
>
> Supporting objects allows one to easily handle the state related to
> callback handling.

You can of course put additional properties on the Function object,
although you couldn’t use an object initialiser.  Maybe we should
discuss this broader question of what what specs should do in general on
public-script-coord?

--
Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 2 June 2011 16:18:34 UTC