W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2004

Re: DOMErrorHandler, EventListener, et al in ECMAScript binding

From: Johnny Stenback <jst@w3c.jstenback.com>
Date: Thu, 11 Mar 2004 11:33:59 -0800
Message-ID: <4050BF27.8070103@w3c.jstenback.com>
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

Received on Thursday, 11 March 2004 14:34:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:12 UTC