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

-- 
jst
Received on Thursday, 11 March 2004 14:34:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:13:57 GMT