std.signals2 proposal

[Robert]

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.