>
> First of all, for all you joining late to the event discussion from
> several threads back; there's an Event patch [1] sitting in Trac for some
> time now that handles a lot. This and Colin's patch [2] don't overlap in
> functionality as much as in code; some clever merging will be required to
On 2/9/07, Colin Mollenhour <[EMAIL PROTECTED]> wrote:
>
>
> I think this patch has become quite refined and mature by now, I'd love to
> get some more feedback from the Core guys...
>
First of all, for all you joining late to the event discussion from several
threads back; there's an Event patch
> I've been doing a lot of research on the subject of Event registration.
> It made me question: do we really need to detach listeners in IE on
> unload? Unless anyone knows for sure, I plan to test.
According to what I've read primarily here:
http://javascript.crockford.com/memory/leak.html
it
I should point out that made the return value a simple int rather than
an object with a stopObserving function.
It would be quite easy to add, simply change (in EventCache.observe):
return this.cacheIndex;
to:
return {stopObserving: EventCache.stopObserving.bind(this,
this.cacheIndex)};
But,
> Colin, thanks for pointing out that my observer array will slow things
> down in many cases. I really like your implementation, especially the
> way you keep a different EventCache object. One thing I wonder, though,
> if like you said your function returns an index--an array index could be
> p
Ken Snyder wrote:
> Along with all this Event handling discussion, I'd like to throw in my
> ideas for a rewrite of Event.observe et al before I test and submit as a
> patch. My proposed changes allow the traditional Event.stopObserving()
> and simplify some of the current messaging ideas. Pl
