This sentence is backwards. There are not problems if the *source* has a shorter or equal lifetime as the *listener*, because it is the source which is preventing the listener from being collected.

Which one are not working for you? If you let me know I can fix them

Colin E.

I meant it’s easy making strong ref from weak ref but not the other way around.

This brings me to another point.

This unpredictability is inherent to everything that uses weakref – such as Threading.Timer. Once ‘dead’ (as per your definition), the timer event may still fire a few times before it gets GC’ed, thus introducing unpredictability. That simply means you need to care about its lifetime and dispose it when you want it to stop. Same principle applies to weak events, you’d still care about its lifetime and remove the event handlers at the correct point. For consistency, I’d prefer all events be changed to weak events by default (should have been this way from the get-go). It’s easy to make a strong ref to an object from a weaf-ref, whereas an implicit strong ref makes it hard to break (in fact, it’ll be impossible if the event is in a third-party library where you wouldn’t want to change the source / haven’t got the source). The overhead to assign and call a weak event if supported natively is negligible. And with events being weak by default, developers are forced to think about the object, as opposed to the method they want triggered, when they hook it to the event.

However, if this UI module handles events from an object with a longer lifetime, the ‘application’ object for example, and you do not remove the event handlers when the UI module is no longer used, a strong reference will still exist and it will not be GC’ed at the point you might expect. If you use weak events, the weak reference will mean that this module will be GC’ed if the only reference that exists to it is via the weak event and a memory leak no longer occurs.

However, what if the UI modules event handler performs some non-trivial logic? Perhaps as a result of handling an event from an application it writes to a database, or uses a web service? With a weak event reference this logic could be executed a number of times before the UI module is GCed. This leads to an application which behaves in an unpredictable manner.

I am not against weak events in principle. What I am against is the liberal use of them in instances where all the developer has to do is remove their events handlers at the correct point in the code. If you do so, you will never have event handlers being executed at unpredictable points in time.

Hope that helps,
Colin E.

How so? A strong ref would need to have been made prior to the event being called. And once it’s called, the object’s this pointer becomes live and traceable from root. So, GC won’t collect it while it’s being executed.

Colin E.