- From: Johnny Stenback <jst@w3c.jstenback.com>
- Date: Thu, 11 Mar 2004 11:33:59 -0800
- To: Curt Arnold <carnold@houston.rr.com>
- Cc: www-dom@w3.org
Curt Arnold wrote: > > Being able to pass in either a JS function or an object sounds desirable > in those instances sounds desirable, but I don't see justification for > it in the current ecmascript binding description. I assume that you do > not anticipate any implementation difficulties if it took either form. I don't see any technical problems either way, but not allowing functions to be passed would be an inconsistency with the handling of existing callback-like interfaces. I strongly encourage a change to the ecmascript bindings to reflect this. > > > On Mar 11, 2004, at 12:12 AM, Johnny Stenback wrote: > >> >> Curt Arnold wrote: >> [...] >> >>> It is pretty explicit that a function object is used for >>> EventListeners and NodeFilters. Am I right in interpreting that the >>> DOMErrorHandler, UserDataHandler, LSSerializerFilter, LSParserFilter >>> and ResourceResolver are passed as objects, something like: >> >> >> I would argue that it should be able to pass a JS function as any >> callback interfaces that contain only one method (i.e. one method, no >> attributes, but constants are ok). That would mean that one can pass a >> JS function as a DOMErrorHandler, UserDataHandler, or >> LSResourceResolver, but not as a LSSerializerFilter nor as a >> LSParserFilter. >> >> -- >> jst >> > -- jst
Received on Thursday, 11 March 2004 14:34:03 UTC