Signals and Slots in D

[Lutger]

Walter Bright wrote:
> Lutger wrote:
>> Almost, it's very simple, like the plain old function pointer as 
>> callback in C. The main difference is:
>> - when an object which has member functions connected gets detroyed, 
>> there is no problem, no segfaults.
> 
> Doesn't garbage collection automatically take care of that?

Yes, but you'd have a reference to a dead object in your delegate array 
when it gets deleted and then you emit a signal. You can of course 
remove that reference when you so want to delete an object, then you 
have to track them and miss some ease of use. Or let some language / 
library do it for you.

>> - signals and slots are not as tightly coupled to a specific class as 
>> in your example. Be it through introspection or ifti, class B needs to 
>> know nothing about A except where it can connect, meaning more less 
>> coupling between classes. I think thats all there is to it in essence.
> 
> I think that is easily handled with a naming convention - call A.connect().

Yes, this is also a convention amongst different libraries (I like the 
~= syntactic sugar though. C# events use the += operator btw). Given 
this convention, some boilerplate code and a way to delete objects 
without needing to manually call A.disconnect(&foo), there are two 
things missing, but they could be left out:
- Signals as a seperate struct or class instead, no need for a signal to 
be limited to be a member of some class.
- It should work for all callable types.