Design thought for callbacks

[Cem Karan]

On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa <marko at pacujo.net> wrote:

> Chris Angelico <rosuav at gmail.com>:
> 
>> On Sat, Feb 21, 2015 at 1:44 PM, Cem Karan <cfkaran2 at gmail.com> wrote:
> 
>>> In order to inform users that certain bits of state have changed, I
>>> require them to register a callback with my code. The problem is that
>>> when I store these callbacks, it naturally creates a strong reference
>>> to the objects, which means that if they are deleted without
>>> unregistering themselves first, my code will keep the callbacks
>>> alive. Since this could lead to really weird and nasty situations,
>>> [...]
>> 
>> No, it's not. I would advise using strong references - if the callback
>> is a closure, for instance, you need to hang onto it, because there
>> are unlikely to be any other references to it. If I register a
>> callback with you, I expect it to be called; I expect, in fact, that
>> that *will* keep my object alive.
> 
> I use callbacks all the time but haven't had any problems with strong
> references.
> 
> I am careful to move my objects to a zombie state after they're done so
> they can absorb any potential loose callbacks that are lingering in the
> system.

So, if I were designing a library for you, you would be willing to have a 'zombie' attribute on your callback, correct?  This would allow the library to query its callbacks to ensure that only 'live' callbacks are called.  How would you handle closures?  

Thanks,
Cem Karan