• Robert (54/54) Nov 24 2012 Hi there!

Robert <jfanatiker gmx.at> writes:

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
semantics)

- 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


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

Code can be found at:
https://github.com/eskimor/phobos/blob/new_signal/std/signals.d (will be
renamed to signals2.d eventually)

There is just one thing in the way:
http://d.puremagic.com/issues/show_bug.cgi?id=8441

Because of this, my current mixin wrapper does not compile, it seems to
be somewhat related to:
http://d.puremagic.com/issues/show_bug.cgi?id=9053

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,

Robert

*) 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, ...