signal slots (new, fixed version)

[Bill Baxter]

Lutger wrote:
> After Bastiaan Veelo's post I realized my signal slots library should be 
> rewritten, which is now mostly done. You can get the result or browse 
> the docs here:
> lutger.ifastnet.com
> 
> Unreferenced objects are now properly garbage collected and 
> disconnected, emitting a signal (should) incurs less overhead,
> both memory- and performance wise.
> 
> It still needs some testing and a little work, but it's functional.
> 
> Features:
> - free functions, delegate literals and delegates can act as slots
> - clean syntax, freestanding signals.
> - emitting signals are locked to prevent possible stack overflow, can be 
> turned off with version=Unsafe.
> - can set a default handler, which is invoked when a signal is emitted 
> that has no slots connected.
> - signals can have return values.
> - signals have opApply and opApplyReverse for custom iteration, mapping 
> and combining return values.
> 
> Example:
> 
> import std.stdio, sslot.signal;
> 
> class Button
> {
>     this() { onClick = new Signal!(); }
>     Signal!() onClick;
> }
> 
> class Receiver : ISlotTracking
> {
>     void handleClick() { writefln("button clicked"); }
>     mixin SlotTracking;
> }
> 
> Button   button   = new Button;
> Receiver receiver = new Receiver;
> button.onClick.connect(&receiver.handleClick, receiver);
> button.onClick();  // prints 'button clicked'
> 
> Signal!(int,int) signal = new Signal!(int,int);
> 
> signal ~= (int num) { return num * num; };
> assert(signal(3) == 9);


It seems like having a return value in the slot that differs from the 
return value on the signal results in the slot silently not getting called.

I'd like to be able to have a Signal!(void,int) but be able to call a 
method that returns something like "int method(int var)".  A signal with 
void return should be able to just ignore the return value.

At the very least the connect attempt should fail if the slot isn't 
going to actually get called.

Other than that it seems to work pretty well.

Is there no way the Signals can be initialized automatically?  It's 
pretty ugly to have to do a new Signal in my constructor for every 
signal I want to declare.  Actually I was getting crashes for the first 
little while before I realized I had to do that.

--bb