std.signals2 proposal

[eskimo]

> _tab.closed.connect((sender,args)=>this.Dispose());
> 
> If the closure dies prematurely, it won't free resources at all 
> or at the right time. Although you currently keep a strong 
> reference to closures, you claim it's a bug rather than feature. 
> You fix deterministic sloppiness of memory leaks at the cost of 
> undeterministic sloppiness of prematurely dying event handlers 
> (depending on the state of the heap).

Now I see where this is coming from, you got that wrong. It is an
absolute must to have a strong ref to the closure. Otherwise it would
not work at all, but the signal should not keep "this" from your example
alive, which is obviously not possible, because it would break the
closure, also the signal has no way to find out that this.Dispose() is
eventually invoked.

The trick that solved both problems is that I pass the object to the
delegate, instead of hiding it in its context. This way I don't have a
strong ref from the delegate, which would keep the object alive and the
signal can tell the runtime to get informed when the connected object
gets deleted.

The thing I claimed a side effect (not a bug, it really is not) is that
you can create a strong ref to the object easily, by issuing connect
with null for the object and simply contain the object in the delegates
context. This way also struct methods and other delegates can be
connected to a signal, but with strong ref semantics.

Maybe this misunderstanding was caused by this thread unfortunately
being split up in two threads, so you might have missed half of my
explanation and examples: One is starting with "std.signals2 proposal"
and one staring with "RE: std.signals2 proposal".

Best regards, 

Robert