- From: <keshlam@us.ibm.com>
- Date: Mon, 27 Mar 2000 11:31:20 -0500
- To: www-dom@w3.org
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 UTC