Re: Proposed change in removeEventHandler semantics

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

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

> 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

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