views:

302

answers:

4

I have an object (Delegate) which needs to stay alive (not garbage collected) while another object (TargetObject) is alive. I want Delegate to be garbage collected when TargetObject is collected (or at least available for collection).

The difficulty is that I don't want to need to reference Delegate from TargetObject since I want it to work for existing objects unaware of Delegate, and I don't want to affect the lifetime of TargetObject. Is this at all possible?

Thanks.

Edit: Thanks for the responses so far. I'll try to clarify what I'm up to.

I'm trying to implement weak events but I'm not a fan of the WeakEventManager (particularly IWeakEventListener). I want to hold a weak reference to a delegate event handler (Delegate) which points to a method in object TargetObject. There needs to be a strong reference to Delegate while TargetObject is alive to keep Delegate alive, but if something with a longer lifetime references Delegate, it keeps TargetObject alive (defeating the purpose of the weak event).

It would be nice if objects subscribing to weak events didn't have to have any special implementation details such as having to hold on to a collection of delegates.

Edit Edit: Changed 'A' to 'Delegate' and 'B' to 'TargetObject'

A: 

I don't think it's good design to have an "alive" object that doesn't have any references to it.

You could always create a static List with references to objects that should stay alive, but of course you'd have to manage that yourself.

I don't see a clean solution for that, but maybe some of the super-beings on StackOverflow will come up with a solution.

Philippe Leybaert
That's what I'm hoping...
AndrewS
+2  A: 

This sounds like a design issue to me. If B doesn't need to know about the instance of A, why do you care about whether A is alive or not?

You can possibly do this using a container object with a weak reference to B and a strong reference to A, and a timer periodically checking whether the weak reference is still alive... but it would be a pretty grotty hack.

If you can explain why you think you need this, we may be able to suggest a better approach.

Jon Skeet
I'll definitely avoid the timer approach :)My current thought is that I'll have to make B reference A, but another (cleaner) solution would be nice.
AndrewS
A: 

Throw an event in the destructor (finalize) method of B, and write a handler for that event that kills A.

Console
This would require a reference from B to A, and specific implementation which is what I'm trying to avoid.
AndrewS
You would not need a reference, you would just need something in your application that can respond to the event from B and tell A to die. Having read your updates I guess your case is more complicated in ways I haven't fully understood. :)
Console
+1  A: 

Why don't you just reference A from B?
That will keep A alive and does not require A to be aware of B...

Niklas
Sorry, my question should have read "I want it to work for existing objects unaware of A". A can reference B but not vise versa.
AndrewS