Andrej Mitrovic wrote: >>From what I can tell std.signal is designed around the idea that an >entire class acts as a signal emitter, without the ability to write >multiple signals within one class and making arbitrary connections >between signals and slots. > >If you actually read the full paper it links to: >http://www.elpauer.org/stuff/a_deeper_look_at_signals_and_slots.pdf > >you'll see that the idea of signals and slots is to avoid writing >specialized signal classes, and instead just use member functions as >signal emitters. > >I don't see why we can't have something as good or even better than >Qt's and Boost's signals and slots implementations. I admit I haven't >had a look at the other implementations linked from the std.signals >page yet, so maybe there's some better implementations out there. But >from a current standpoint it looks to me like std.signal is a good >candidate for a revamp.
I started a std.signal rewrite ~1 year ago: This is what I came up with: http://dl.dropbox.com/u/24218791/d/src/signals.html https://gist.github.com/1194497 I think the API isn't too bad, but the internal implementation could be improved. I didn't know about boost.signals, so that could be used to improve my implementation. However, I think it's useless as long as it can't be used by multiple threads. But when I wanted to add 'shared' support to it, I always hit a dead end, a bug, something not working, so in the end I gave up. Another point which could be improved is that it currently only works for @safe/@trusted delegates. Maybe a @system signal is also useful. And I'm also not sure how (or whether) signals are meant to be integrated with message passing. -- Johannes Pfau
