I've uploaded a new version using the features of D since 0.173. Perhaps it is useful to those who want return values and other callable types than delegates from objects in their signals:

http://lutger.ifastnet.com

Some changes:
- No need for interface + mixin anymore to manage connections.
- No limit to the number of arguments.
- Slots can be temporarily blocked and unblocked.
- As suggested by Bill Baxter, a signal which doesn't have a return value can connect any slot with a return value.
- Better compiler time error messages. I've included Don Clugston's meta.nameof for this, I'm sure it has an open source license but I couldn't find exactly which one.
- Classes can be injected with the signal code by using a mixin.
A test module is included.

Note that connecting is slightly different from phobos, you'll have to provide the object reference:
signal.connect(&foo.bar, foo) instead of just signal.connect(&foo.bar)

[OT] I have to say it is a pleasure to program in D. The template varargs is a godsend.

Lutger wrote:
> I've uploaded a new version using the features of D since 0.173. Perhaps it is useful to those who want return values and other callable types than delegates from objects in their signals:
> 
> http://lutger.ifastnet.com

Sounds like good stuff, Lutger.

In the mean time, I've also updated FlexSignal to support connecting a function like:
   bool foo_slot(char[] s) { ... }

to the signal:
   FlexSignal!(int, char[], float);

I.e. the foo_slot can be connected to only get the char[] argument if that's all it's interested in.  Unfortunately the syntax for this is a little cumbersome right now due to bug #540:

    thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot);

When/if #540 is fixed this can become:

    thesignal.fconnect!(1)(&foo_slot);

The '1' indicates foo_slot wants to skip the 1st argument emitted by the signal.

Source here:
http://www.dsource.org/projects/luigi/browser/trunk/luigi/signalobj.d

Unlike Lutger's version, this is a wrapper around std.signals, and so signals can't have a return value.

--bb

On Fri, 17 Nov 2006 09:06:45 -0800, Lutger <lutger.blijdestijn@gmail.com> wrote:

> I've uploaded a new version using the features of D since 0.173. Perhaps it is useful to those who want return values and other callable types than delegates from objects in their signals:
>
> http://lutger.ifastnet.com
>
> Some changes:
> - No need for interface + mixin anymore to manage connections.
> - No limit to the number of arguments.
> - Slots can be temporarily blocked and unblocked.
> - As suggested by Bill Baxter, a signal which doesn't have a return value can connect any slot with a return value.
> - Better compiler time error messages. I've included Don Clugston's meta.nameof for this, I'm sure it has an open source license but I couldn't find exactly which one.
> - Classes can be injected with the signal code by using a mixin.
> A test module is included.
>
> Note that connecting is slightly different from phobos, you'll have to provide the object reference:
> signal.connect(&foo.bar, foo) instead of just signal.connect(&foo.bar)
>
> [OT] I have to say it is a pleasure to program in D. The template varargs is a godsend.


Nice, but the document refers to a test.d or something that shows more details on how to use sslot.  It's not in the package, and I don't see any other examples anywhere.

-JJR

John Reimer wrote:
 > Nice, but the document refers to a test.d or something that shows more
> details on how to use sslot.  It's not in the package, and I don't see any other examples anywhere.
> 
> -JJR

That's weird. Did you download the archive sslot_v0.2.tar.gz? There should be a module tests.d inside. The documentation also has a couple of examples, it's in sslot\doc\signal.html, the same is viewable online.

Bill Baxter wrote:
> In the mean time, I've also updated FlexSignal to support connecting a function like:
>    bool foo_slot(char[] s) { ... }
> 
> to the signal:
>    FlexSignal!(int, char[], float);
> 
> I.e. the foo_slot can be connected to only get the char[] argument if that's all it's interested in.  Unfortunately the syntax for this is a little cumbersome right now due to bug #540:
> 
>     thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot);
> 
> When/if #540 is fixed this can become:
> 
>     thesignal.fconnect!(1)(&foo_slot);
> 
> The '1' indicates foo_slot wants to skip the 1st argument emitted by the signal.

It's sort of a reverse bind? Would it be possible to write a seperate adapter so it could be used with std.signals and allow for garbage collection / deletion before disconnection?
Boost::signals works nicely with boost bind like this but it's a little less flexible iirc.

Something like this perhaps:
thesignal.connect(adapt(thesignal, &foo_slot, 1));

and / or more concise:
connect(thesignal, &foo_slot, 1);


btw. there is a way to get the type of the .ptr property of a delegate but I was reluctant to use it as it seemed a little too hackish:
http://www.digitalmars.com/d/archives/digitalmars/D/learn/delegate_type_info_5001.html

On Sat, 18 Nov 2006 05:07:26 -0800, Lutger <lutger.blijdestijn@gmail.com> wrote:

> John Reimer wrote:
>   > Nice, but the document refers to a test.d or something that shows more
>> details on how to use sslot.  It's not in the package, and I don't see any other examples anywhere.
>>  -JJR
>
> That's weird. Did you download the archive sslot_v0.2.tar.gz? There should be a module tests.d inside. The documentation also has a couple of examples, it's in sslot\doc\signal.html, the same is viewable online.


Yes, I saw the doc examples. And Yes, tests.d was inside.  Sorry, my mistake.  I must have been looking in the wrong place.

:P

-JJR

Lutger wrote:
> Bill Baxter wrote:
>> In the mean time, I've also updated FlexSignal to support connecting a function like:
>>    bool foo_slot(char[] s) { ... }
>>
>> to the signal:
>>    FlexSignal!(int, char[], float);
>>
>> I.e. the foo_slot can be connected to only get the char[] argument if that's all it's interested in.  Unfortunately the syntax for this is a little cumbersome right now due to bug #540:
>>
>>     thesignal.fconnect!(typeof(&foo_slot),1)(&foo_slot);
>>
>> When/if #540 is fixed this can become:
>>
>>     thesignal.fconnect!(1)(&foo_slot);
>>
>> The '1' indicates foo_slot wants to skip the 1st argument emitted by the signal.
> 
> It's sort of a reverse bind? 

Yeh, it is sort of bind-like.

> Would it be possible to write a seperate adapter so it could be used with std.signals and allow for garbage collection / deletion before disconnection?

It does actually use a separate adaptor.  See the SlotAdaptor template in the code.
But right now the SlotAdaptor template only returns the pointer to the delegate it makes, not the class itself.  But I guess you could get that from the .ptr prop.



> Boost::signals works nicely with boost bind like this but it's a little less flexible iirc.
> 
> Something like this perhaps:
> thesignal.connect(adapt(thesignal, &foo_slot, 1));

The problem with that is that it creates some adapted thingy but unless you keep a pointer to it yourself you won't have a way to disconnect it.

> and / or more concise:
> connect(thesignal, &foo_slot, 1);

That doesn't work because the '1' has to be a compile time constant in order to muck with the signal's argument tuple.  I don't think there's a way to convince D that it is constant without making it a template parameter.  At least I couldn't figure one out.

> btw. there is a way to get the type of the .ptr property of a delegate but I was reluctant to use it as it seemed a little too hackish:
> http://www.digitalmars.com/d/archives/digitalmars/D/learn/delegate_type_info_5001.html

Ah yes.  I remember seeing that one go by.  Hopefully some official support for that will be added, or else the distinction between Object and non-object delegates will be removed.

--bb

Lutger wrote:
> I've uploaded a new version using the features of D since 0.173. Perhaps it is useful to those who want return values and other callable types than delegates from objects in their signals:
> 
> http://lutger.ifastnet.com
> 
> Some changes:


> - Better compiler time error messages. I've included Don Clugston's meta.nameof for this, I'm sure it has an open source license but I couldn't find exactly which one.

BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Don Clugston wrote:
> Lutger wrote:
>> I've uploaded a new version using the features of D since 0.173. Perhaps it is useful to those who want return values and other callable types than delegates from objects in their signals:
>>
>> http://lutger.ifastnet.com
>>
>> Some changes:
> 
> 
>> - Better compiler time error messages. I've included Don Clugston's meta.nameof for this, I'm sure it has an open source license but I couldn't find exactly which one.
> 
> BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Good to hear. I'm sure there are much more impressive things that can be done with it, but being able to give such exact compiler messages is pretty darn useful I've found.

It must be in the top 3 complaints from people learning STL that the compiler error messages are so cryptic. By using D templates with meta.nameof it might be possible to make templated code even easier to 'debug' than non-templated code. I think this can be a huge time-saver.

Don Clugston wrote:
> Lutger wrote:
>> - Better compiler time error messages. I've included Don Clugston's meta.nameof for this, I'm sure it has an open source license but I couldn't find exactly which one.
> 
> BSD. I'm working on an update which will cope with all situations (the one in DDL/meta doesn't work with local variables (it wasn't possible prior to 0.172), and fails in some (relatively obscure) circumstances).

Your Nameof module is turning out to be exceedingly useful. Pyd also uses it. I have some license questions/requests:

I would appreciate it if (in the future) you included the text of the license at the top of the source files (in a plain comment, not a doc-comment).

Second, Pyd itself is released under the MIT license. If Wikipedia's rundown of the differences between the two is correct, then to comply with the BSD license on Nameof I just need to include "meta.Nameof and meta.Demangle are copyright (C) 2005-2006 Don Clugston" in Pyd's docs. Is this correct?

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org