Design thought for callbacks

[Cem Karan]

On Feb 22, 2015, at 7:12 AM, Marko Rauhamaa <marko at pacujo.net> wrote:

> Cem Karan <cfkaran2 at gmail.com>:
> 
>> On Feb 21, 2015, at 11:03 AM, Marko Rauhamaa <marko at pacujo.net> wrote:
>>> 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?
> 
> Sorry, don't understand the question.

You were saying that you move your objects into a zombie state.  I assumed that you meant you marked them in some manner (e.g., setting 'is_zombie' to True), so that anything that has a strong reference to the object knows the object is not supposed to be used anymore.  That way, regardless of where or how many times you've registered your object for callbacks, the library can do something like the following (banged out in my mail application, may have typos):

"""
_CALLBACKS = []

def execute_callbacks():
    global _CALLBACKS
    _CALLBACKS = [x for x in _CALLBACKS if not x.is_zombie]
    for x in _CALLBACKS:
        x()
"""

That will lazily unregister callbacks that are in the zombie state, which will eventually lead to their collection by the garbage collector.  It won't work for anything that you don't have a reference for (lambdas, etc.), but it should work in a lot of cases.

Is this what you meant?

Thanks,
Cem Karan