On Fri, 2012-11-09 at 19:28 +0100, Kagamin wrote: Huh? I don't get it. Didn't you want weak ref semantics for > signals? Why do you want strong ref semantics now? >
There is a distinction between the context of a delegate, which is used for parameter transformation or other advanced stuff and the final destination object. The first one is very likely that only the signal has a reference to it (think of lamdas), and thus the signal holds a strong ref to it. For the object, which method gets eventually invoked, the signal does not hold a strong ref, instead it simply drops the slot when the object gets deleted. In your example, to make it work with weak ref semantics with the new signal implementation: _tab.closed.connect(this, (obj, sender,args)=>obj.Dispose()); instead of: _tab.closed.connect((sender,args)=>this.Dispose()); (obj, sender,args)=>obj.Dispose() is in this case just a function or a delegate with null ptr as context. But if there were a context the signal would keep it in memory. The object which gets explicitly passed to the delegate via obj, is only weakly referenced from the signal. The whole purpose is to make indirect connections to an objects method possible, for parameter transformations, parameter omissions, for providing additional parameters, ... If you want a direct connection you would use the simpler: signal.connect!"Dispose"(this); as explained in my initial post.