Signal, event and bicycle

[Robert]

>
> - why with this simple task we should use a rt_... magic?

Because D has no built in weak references.

> - why rt_... hooks is used like dtors?

you drop your slots when the object gets collected.

> - why to write a simple iterator over container and calling its 
> data we need above magic?

just because of weak ref semantics, if you drop this requirement 
it becomes a simple delegate array.

> - if I will see problems in signals implementation, why I need 
> to know about "hidden" references that GC not sees?

The GC is not allowed to see it, so it will collect the objects 
if no references are left. By means of the rt_ hooks you get 
notified about this and can drop your hidden reference.

> - what if rt_... or GC behaviour will changed and it's will not 
> possible using standard and documented language features in 
> this case?

In this case the implementation would need to be fixed, but 
fortunately everything is hidden, so the API would not change, 
meaning no user code should break.

 From a quick glance at your code, I believe you are using the 
hooks wrong. In particular, what's the purpose of:

  this.attachOnDestroy(&onSelfDestroy);

?

Also I don't see where you are hiding the references from the GC. 
If you don't need weak ref semantics, simply drop all this rt_ 
stuff you won't need it.


phobosx.signal gets a bit complicated because:
  - weak refs
  - thread safety in regard to the GC semantics. (destructors are 
called in parallel with other threads already active again.)
  - I wanted to minimize the memory footprint.
  - I wanted to minimize templated code (not sure this is really 
worthwhile, so this might be changed)
  - It is possible to have only the containing class being able to 
emit the signal.
  - It is correct even if slots are manipulated during the call to 
emit. (From a slot for example.) And even for the partially 
concurrent working of the GC.

In summary I believe almost all complexities of the 
implementation are necessary for a standard implementation of 
signals.


Best regards,
Robert