std.signals regressions

[Johannes Pfau]

Am Sat, 13 Jul 2013 15:47:35 +0200
schrieb David <d at dav1d.de>:

> Am 13.07.2013 10:14, schrieb Robert:
> > 
> >>>>
> >>>> [1]https://github.com/AndrejMitrovic/new_signals
> > 
> > 
> > Hmm, ok this implementation does not implement weak ref semantics,
> > but it does implement some fancy features like enabling/disabling
> > emission, adding slots at a specified position and stuff. At least
> > for enabling/disabling I decided not to include it for now, to keep
> > the implementation simple and I also think it is not really needed.
> > But in general what features of your new_signals implentation do
> > you really need/like that are not present in my implementation?
> > Ideally with use cases so I can get an idea? Thanks for the
> > feedback!
> > 
> > Best regards,
> > 
> > Robert
> 
> What I like? It works and it was a opt-in for my old code (s/mixin
> Signal/Signal/), but you need to probably break the API-compatability
> with the weak ref thing.
> I don't really need the "stop propagation", "insert before/after",
> but I can see where it can come in handy.
> 
> So far, I was really really happy when Andrej came up with this code,
> I really really needed something else than the old std.signals and
> this does exactly what I needed.

When I initially wrote that code I wanted it to support everything that
usual C/C++ signal implementations support. I looked at what features
glib offered and implemented most of them.

I was never sure whether a list as the internal data structure was the
right choice though. I wanted to have a look at boost's signal
implementation and especially do some more performance testing. Then I
somehow forgot about it and it never seemed like there was a big
demand for signals so I never finished that work.

Anyway feel free to take anything you need from that code. I
unfortunately don't have much time right now to help integrate those
implementations but merging them would probably be a good idea.

But one comment though: Do you really need string mixins? I think
"Signal!int mysignal;" is a much nicer syntax in D than using mixins /
string mixins. And I think it's also quite important that a signal
implementation works with all of D's callable types - especially
functions and delegates but opCall is nice as well.