RE: [Events] removeEventListener on EventListeners currently bein g processed

> -----Original Message-----
> From:	David Brownell [SMTP:david-b@pacbell.net]
> 
> > So , you mean that adding an event listener to a list currently being processed
> > should be invoked? If so, I don't see why this is "appropriate".
> 
> Keeping an API model self-consistent is _always_ appropriate.
> 
	That's a pretty broad generalisation don't you think?

> >     This is not about
> > symmetry, it's about potentially provoking code that may not longer be valid
> > due to dangling pointers, inconsistent state, etc.
> 
> So you deny that the resolution of that issue created an
> inconsistency in the API model?  
> 
	Yes. It is an exceptional thing to do. But I believe it is a necessary for exactly
	the reasons Phillipe pointed out.

> >     I think when an event is
> > dispatched, it should try to appear as an atomic operation, meaning a copy of
> > the listener list is used. 
> 
> Atomic != "use a copy".
> 
	That's why I said "_appear_ as an atomic operation".

>   The change I identified is as
> atomic as the current text, but it's got the same model
> for the add and remove tasks.
> 
	This is aesthetic reasoning with no practical merit. In an ideal system, the
	operations would trigger all event listeners in parallel as an atomic operation
	on a snapshot of the DOM's state in which case this whole issue would be
	moot because one listener could not remove another and see the effects.
	Unfortunately, until we start using quantum computers we'll have to continue
	to trigger listeners synchronously in which case this removal of an event
	listener must be dealt with for the reasons outlined.

	IMHO,

	Mike

Received on Monday, 20 August 2001 19:24:52 UTC