November 24, 2012
Hi there!

My std.signals2 implementation is already in quite a good shape and feature complete, improvements over std.signals:

- safe connect method to an object's method (weak ref semantic)

- support for indirect connect to an object's method via a wrapper delegate (weak ref semantics to target object)

- strongConnect method for connecting to non objects. (strong ref

- disconnect method for disconnecting all methods of a given object with a single call.

- Proper exception handling. Meaning if a slot throws an exception the other slots will still be called and all slot exceptions are chained together.

- signals methods are safe to call from within a slot. (For
disconnecting, and even for emit() and stuff, which is useful if you
think of fibers.) This is not yet tested, but it should work.

- signal copying is forbidden, as it can not be made to work with D's relocatable structs. (Current std.signals triggers a segfault)

- Signals are implemented as structs *) instead of a mixin and every template parameter agnostic code also does not depend on the template parameters -> avoid template bloat.

- Memory footprint for empty signal is even lower than the one of the current std.signals, which is important because many signals end up not being used at all.

- Provided mixin wrapper which allows only the containing class to issue emit(), but everyone to connect.

- Memory allocations are kept to a minimum necessary

- Update documentation
- Write more unittests
- Rename to std.signals2

Code can be found at: (will be renamed to signals2.d eventually)

There is just one thing in the way:

Because of this, my current mixin wrapper does not compile, it seems to be somewhat related to:

but I am not sure. If someone out there with compiler writing experience wants to have my super cool std.signals2 in phobos, you might wanna have a look at this issue.

On the other hand I could use some string mixin, but I think the result would be less nice, nevertheless I am open for suggestions. The result should be, that it is just one line of code to have a signal in your class which only the implementation of the class (ok in D the containing module) can emit, but everyone can connect to.

Thanks for any suggestions or fixes :-)

Best regards,


*) A signal is implemented as a struct, so it is an entity on its own which can be referred to. This can be useful for things like connection managers, where you can pass signals to them and they take care of connecting slots to all of them, ...