Community

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