- 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
