Re: event registration another way

> >If I had it my way, I'd rather that removeEventListener
> >method had to be called as many times as addEventListener

Ditto.  That's the way I'm used to working with interface
layering abstractions ... the layers should not be required
to know about each other.  Non-modular design causes major
trouble in system evolution, even when you DO control every
bit of code that can run in there.

And in fact when I implemented the event stuff over a year
ago (!!) that's how I did it.  So far as I recall, it was
correct at the time; I certainly don't recall noticing that
a strange idiom was being used.


> >but still insist that the event listener be called only once.

Hmm.  That sounds like an optimization to me, and I usually
hate to see them written into specs.


> Interesting point re deregistering restoring the state before the
> registration, for "stacking" purposes. If we'd thought of it, I think we
> might have gone that route.

Actually I'd say it the other way around.  You have to do extra
work to care about identity.  Someone must clearly have thought
about this, to write "do extra work" into the spec, and avoid
using that standard idiom.

What's the rationale for caring about identity?  Perhaps it's
to avoid handlers seeing events more than once?

- Dave

Received on Friday, 29 September 2000 14:17:58 UTC