- From: David Brownell <david-b@pacbell.net>
- Date: Mon, 20 Aug 2001 17:11:10 -0700
- To: "Allen, Michael B (RSCH)" <Michael_B_Allen@ml.com>
- Cc: www-dom@w3.org
> > > 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? You seem to think that's a bad thing; why? There's cognitive science behind that principle, as well as years of practical experience. Self-inconsistent models are error prone; special cases tend to make bugs happen. More people trip over the pavement that's raised an extra few inches (say, by a root) than over the flat stuff. > > > 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 don't seem to have a message from Phillipe with any reasons. The archive discussion doesn't address that issue (that is, it was raised a couple times but ignored). > > > 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". ... "meaning a copy ... is used". Sure looks to me like you said the two concepts are one and the same. > > 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. You lost me there. "Atomic" has clear technical meaning, "same model" has one that seems clear in context. You did not respond to either aspect. Were you responding to some other post, which used a "fighting word" like "ugly"? > 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. And that's irrelevant to the consistency issue, which was raised along with the original proposal yet which is still unresolved. - Dave
Received on Monday, 20 August 2001 20:12:35 UTC