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

Re: Proposed change in removeEventHandler semantics

From: <keshlam@us.ibm.com>
Date: Mon, 27 Mar 2000 11:31:20 -0500
To: www-dom@w3.org
Message-ID: <852568AF.005AC0C6.00@D51MTA03.pok.ibm.com>
Quoth Raph, responding to me:
> > Are you sure you like not knowing whether the removal will occur before

> or
> > after invocation better than you like knowing that it won't?
>
> I don't understand this. I prefer knowing that the removal suppresses
> subsequent invocation of the handler being removed, even if there is
> an event pending for that handler. I'm not sure that corresponds
> exactly to either of your preferences.

My point was that while this orders the operations of removal and
invocation, you still have no way to control the order of event handlers,
and so the question of whether the handler is or isn't invoked is still
indeterminate.

I see your point about synchronizing the removal (whenever it does occur)
with other work related to that removal, and why you'd like the DOM to
handle that for you rather than your having to maintain a flag of some
sort.

> Is your DOM implementation Xerces-J? Timj, Philippe, and I looked at
> this code at the time we discussed the change, and believe that the
> change can be implemented with a dozen line patch.

As I said: Changing the DOM implementation to handle this might be too bad.
I'm still not sure it's a better behavior for the average DOM-based
application; that's my main point of concern.

Introducing asymmetry between the add and remove behaviors bothers me
somewhat.

(I'm not sure I'm following your reference-count proposal for
implementation; I don't quite see why the count is necessary. I assume I'm
missing something obvious.)



______________________________________
Joe Kesselman  / IBM Research
Received on Monday, 27 March 2000 11:31:57 GMT

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