Is anybody using or planning to use the new signal/slot feature?  Seems like a powerful feature to me.  I'm curious as to its percieved utility to GUI library maintainers.

-Craig

On Tue, 05 Dec 2006 12:38:37 -0500, Craig Black <cblack@ara.com> wrote:

> Is anybody using or planning to use the new signal/slot feature?  Seems like
> a powerful feature to me.  I'm curious as to its percieved utility to GUI
> library maintainers.
>
> -Craig
>

DFL has had something like it all along; just use D's ~= cat-assign operator to attach as many event handlers (delegates) as you want.

The thing is though, that I don't think I want to use std.signals because I actually like that, with DFL's events, an object won't be destructed by the GC if one of the object's member functions is added as an event handler.
For example, take a timer: I have an object and want one of its members called back every second, so I add it to a timer's event; I don't want my object destructed just because I'm not referencing it anymore, I still have the timer setup and want to rely on it to keep on ticking with my live object.
If the timer were to stop and be destructed, then yes, all bets are off and my object can be destructed.

- Chris

Craig Black wrote:
> Is anybody using or planning to use the new signal/slot feature?  Seems like
> a powerful feature to me.  I'm curious as to its percieved utility to GUI
> library maintainers.
> 
> -Craig 
> 

I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps).

It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked.

One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly.

~ Clay

So you are satisfied with the functionality you have with your current design.  OK.  As far as the example that you cited, this seems to be a specific case.  In this case, would it not be a simple matter to maintain a reference to the object that you don't want to be deallocated?

-Craig

"Chris Miller" <chris@dprogramming.com> wrote in message
news:op.tj3ns3mxpo9bzi@tanu...
On Tue, 05 Dec 2006 12:38:37 -0500, Craig Black <cblack@ara.com> wrote:

> Is anybody using or planning to use the new signal/slot feature?  Seems
> like
> a powerful feature to me.  I'm curious as to its percieved utility to GUI
> library maintainers.
>
> -Craig
>

DFL has had something like it all along; just use D's ~= cat-assign operator to attach as many event handlers (delegates) as you want.

The thing is though, that I don't think I want to use std.signals because
I actually like that, with DFL's events, an object won't be destructed by
the GC if one of the object's member functions is added as an event
handler.
For example, take a timer: I have an object and want one of its members
called back every second, so I add it to a timer's event; I don't want my
object destructed just because I'm not referencing it anymore, I still
have the timer setup and want to rely on it to keep on ticking with my
live object.
If the timer were to stop and be destructed, then yes, all bets are off
and my object can be destructed.

- Chris

"clayasaurus" <clayasaurus@gmail.com> wrote in message news:el4evq$1nbu$1@digitaldaemon.com...
> Craig Black wrote:
>> Is anybody using or planning to use the new signal/slot feature?  Seems
>> like
>> a powerful feature to me.  I'm curious as to its percieved utility to GUI
>> library maintainers.
>>
>> -Craig
>
> I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps).
>
> It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked.
>
> One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly.
>
> ~ Clay

As far as performance, I'm sure it's not that bad.  It may be a little less efficient than a regular function call, but since it's primarily used for GUI-related stuff, this small overhead is trivial.

However, if you are concerned, you could do a benchmark.  Put a call to a signal inside a for loop that iterates a bunch of times, and time it.  Test it against a regular delegate invokation, and then a function call.  It would be interesting to see the results.

-Craig

On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack@ara.com> wrote:

> So you are satisfied with the functionality you have with your current
> design.  OK.  As far as the example that you cited, this seems to be a
> specific case.  In this case, would it not be a simple matter to maintain a
> reference to the object that you don't want to be deallocated?
>

But I told the timer to by registering a callback.. *shrug*

I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.

"Chris Miller" <chris@dprogramming.com> wrote in message news:op.tj42pfdcpo9bzi@tanu...
> On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack@ara.com> wrote:
>
>> So you are satisfied with the functionality you have with your current
>> design.  OK.  As far as the example that you cited, this seems to be a
>> specific case.  In this case, would it not be a simple matter to
>> maintain a
>> reference to the object that you don't want to be deallocated?
>>
>
> But I told the timer to by registering a callback.. *shrug*
>
> I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.

I'm not saying you should switch.  It's just worth considering, that's all. If you feel that your current design is better, then no problem.

However, slots and signals are widely used in C++ without language support. With language support this approach is all the more attractive  It would be nice if all GUI libraries written in D used a standard communication mechanism.  Perhaps we could even work toward some sort of interoperability.

-Craig

-Craig

Craig Black Wrote:

> 
> "Chris Miller" <chris@dprogramming.com> wrote in message news:op.tj42pfdcpo9bzi@tanu...
> > On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack@ara.com> wrote:
> >
> >> So you are satisfied with the functionality you have with your current
> >> design.  OK.  As far as the example that you cited, this seems to be a
> >> specific case.  In this case, would it not be a simple matter to
> >> maintain a
> >> reference to the object that you don't want to be deallocated?
> >>
> >
> > But I told the timer to by registering a callback.. *shrug*
> >
> > I guess if majority of people prefer std.signals I'd switch; I might put up a poll on the DFL forum.
> 
> I'm not saying you should switch.  It's just worth considering, that's all. If you feel that your current design is better, then no problem.
> 
> However, slots and signals are widely used in C++ without language support. With language support this approach is all the more attractive  It would be nice if all GUI libraries written in D used a standard communication mechanism.  Perhaps we could even work toward some sort of interoperability.
> 
> -Craig
> 

But isn't the beauty of signals in D that slots are plain delegates that 'just work'. There is already interoperability in this way. Except for acting as a weak reference, signals are the same as arrays of delegates. Or have I missed your point?

clayasaurus Wrote:

> Craig Black wrote:
> > Is anybody using or planning to use the new signal/slot feature?  Seems like a powerful feature to me.  I'm curious as to its percieved utility to GUI library maintainers.
> > 
> > -Craig
> > 
> 
> I made a simple OpenGL based GUI for my little library that uses signal/slots (note I just recently completed it but haven't used it for any apps yet, except for test apps).
> 
> It makes it really easy for users to hook up their own custom code to handle things such as buttons being clicked.
> 
> One thing I'm curious about is the efficiency of signals and slots. I'm guessing it has slightly more overhead than a normal function call, therefore it is not something to be calling constantly.
> 
> ~ Clay

Only way to be sure is to profile, but performance cost should be very small.  It is implemented like this, slot is the delegate:

foreach (slot; slots[0 .. slots_idx])
    if (slot)
        slot(i);

I think usage of signals will only matter if your code would benefit a lot  from being inlined, but better not to do assumptions.

"Lutger" <lutger.blijdestijn@gmail.com> wrote in message news:elft0s$1flt$1@digitaldaemon.com...
> Craig Black Wrote:
>
> >
> > "Chris Miller" <chris@dprogramming.com> wrote in message news:op.tj42pfdcpo9bzi@tanu...
> > > On Tue, 05 Dec 2006 18:54:19 -0500, Craig Black <cblack@ara.com>
wrote:
> > >
> > >> So you are satisfied with the functionality you have with your
current
> > >> design.  OK.  As far as the example that you cited, this seems to be
a
> > >> specific case.  In this case, would it not be a simple matter to
> > >> maintain a
> > >> reference to the object that you don't want to be deallocated?
> > >>
> > >
> > > But I told the timer to by registering a callback.. *shrug*
> > >
> > > I guess if majority of people prefer std.signals I'd switch; I might
put
> > > up a poll on the DFL forum.
> >
> > I'm not saying you should switch.  It's just worth considering, that's
all.
> > If you feel that your current design is better, then no problem.
> >
> > However, slots and signals are widely used in C++ without language
support.
> > With language support this approach is all the more attractive  It would
be
> > nice if all GUI libraries written in D used a standard communication mechanism.  Perhaps we could even work toward some sort of
interoperability.
> >
> > -Craig
> >
>
> But isn't the beauty of signals in D that slots are plain delegates that
'just work'. There is already interoperability in this way. Except for acting as a weak reference, signals are the same as arrays of delegates.
> Or have I missed your point?

It's just frustrating to that there are so many GUI libs for D, but most are not very complete.  Walter tried to remedy this by standardizing on DWT, but it didn't seem to work.  If GUI libs were interoperable, that is, if a widget from one lib could plug into a widget from another, then all library maintainers could work together and share a common code base.

As it is, everybody is doing their own thing.  That's not to be critical of their work.  They're doing more good than I am.  But if everyone used a common approach, perhaps some common abstract classes, then each contributor could contribute to a common GUI library.

Anyway, since signals are part of phobos now, it only seems logical that this could be a common standard.

-Craig