On 7/13/13, David <d@dav1d.de> wrote:
> Bad timing, just got "our"[1] own implementation.
> If I have time, I'll play around with it! Thanks for the great work,
> maybe we can get something working into phobos...
>
>
> [1]https://github.com/AndrejMitrovic/new_signals

Disclaimer: This is the work of Johannes Pfau which I've just hacked and butchered a little bit (and also updated for 2.064) because we needed std.signals that doesn't crash that often.

On Saturday, 13 July 2013 at 01:24:11 UTC, Andrej Mitrovic wrote:
> On 7/13/13, David <d@dav1d.de> wrote:
>> Bad timing, just got "our"[1] own implementation.
>> If I have time, I'll play around with it! Thanks for the great work,
>> maybe we can get something working into phobos...
>>
>>
>> [1]https://github.com/AndrejMitrovic/new_signals
>
> Disclaimer: This is the work of Johannes Pfau which I've just hacked
> and butchered a little bit (and also updated for 2.064) because we
> needed std.signals that doesn't crash that often.

Wow, I wasn't aware of either this implementation nor this thread. Thanks for sharing.

>>>
>>> [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

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.

Am Sat, 13 Jul 2013 15:47:35 +0200
schrieb David <d@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.

> But one comment though: Do you really need string mixins? I think
> "Signal!int mysignal;" is a much nicer syntax in D than using

I agree and you don't need the string mixin, it is just for convenience. The signal itself is a struct. But what was important to me was that one can easily restrict emitting the signal to the containing class. This is where you need some kind of mixin to avoid boilerplate. But if you don't need that or want to write the boilerplate yourself you can just use the FullSignal struct directly.

I wanted to use template mixins because of the little less cluttered syntax, but as it turns out they are quite buggy, so I changed it to a string mixin with the added flexibility that you can select the protection of FullSignal, with private being the default. The syntax does not turn out to be that bad:

  mixin(signal!(string, int)("valueChanged"));

or if you want for example protected instead of private:

  mixin(signal!(string, int)("valueChanged", "protected"));

If you don't want to use the mixin and don't care that everyone can emit the signal:
  FullSignal!(string, int) valueChanged;


You see the mixin is just a feature, if you don't like it - don't use it :-)

> 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.

It does work with all callable types: Delegates/functions and by means of delegates with any callable type.

Best regards,
Robert

On Friday, 12 July 2013 at 22:35:06 UTC, David wrote:
> Am 12.07.2013 23:47, schrieb Robert:
>> I just finished a new implementation, replacing the template mixin with
>> a string mixin. I also changed the name from signals2 to signal. You can
>> find it here:
>> 
>> https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d
>> 
>> All unittests pass, you don't need any patched compiler. I still have to
>> add some more checks and do some polishing, I will also put it in the
>> dub registry. But you seem to have an urgent need, so feel free to try
>> it out immediately - Be my pre-alpha Tester :-)
>> 
>> Best regards,
>> 
>> Robert
>> 
>> 
>
> Bad timing, just got "our"[1] own implementation.
> If I have time, I'll play around with it! Thanks for the great work,
> maybe we can get something working into phobos...
>
>
> [1]https://github.com/AndrejMitrovic/new_signals

Having tried this I can't get ref parameters to work as function arguments, are they supported?

Example:

struct KeyEvent {}

public Signal!(ref KeyEvent) onKeyDown;

connect, emit ...

public void keyDownHandler(ref KeyEvent keyEvent) { }

Works fine without ref.

On 7/14/13, Damian <damianday@hotmail.co.uk> wrote:
> Having tried this I can't get ref parameters to work as function arguments, are they supported?

This is a language issue, you can't pass 'ref' as a template parameter.

Am Sat, 13 Jul 2013 22:37:45 +0200
schrieb "Robert" <jfanatiker@gmx.at>:

> 
> > But one comment though: Do you really need string mixins? I
> > think
> > "Signal!int mysignal;" is a much nicer syntax in D than using
> 
> I agree and you don't need the string mixin, it is just for convenience. The signal itself is a struct. But what was important to me was that one can easily restrict emitting the signal to the containing class.

Now that you mention it I also remember that issue. That's a good reason to use the string/template mixin, although for me clearer syntax had higher priority.