From: "Michael B. Allen" <mballen@erols.com> wrote:
> Meaning an EventListener should be called even if another listener in
> the list currently being processed removes it?
I don't know if the anticipated errata would mandate that behavior or simply
tolerate it. In my non-public implementation, I followed the specified
behavior, but it definitely added complexity.
> I think the implementation
> issue may become even more difficult in languanges with explicit memory
> management though. Currently, my implementation frees a ListenerEntry
> struct when removeEventListener is called. As is, this would result in
> dereferencing a dangling pointer if dispatchEvent attempts to trigger a
> listener after it has been removed. I suspect I must collect the pointers
> to the actull functions to be called for each listener and store that
> in an array (i.e. pre-dereference the listener functions).
Actually, you should already have to collect the listeners since event
listeners added while processing a dispatch to the same target should not
see the event. It was that tension between adding event listeners that
shouldn't be effective until the current event dispatch is complete and
removing event listeners that should be instantaneously effective that made
the implementation a little complicated.
I don't have the code in front of me, but if I remember right, I keep a
document wide count of removeEventListener calls. During the dispatch to an
event, I collect a list of event listeners on that target and start
dispatching to the list. If the count changes during a dispatch to a
particular listener, all other listeners are double checked to see if they
are still registered before dispatching the event.
It would be good to hear the rationale why the behavior in the spec is
undesirable and get a survey of current implementations.
My personal take would be to do whatever is easiest, either following the
spec as written or following Xerces-J's implementation, and wait for the
errata. Also, review the other issues in the message I cited since it also
raises issues between my reading of the spec and Xerces-J's implementation,
however definitely on passages that are ambiguous.