www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Signal, event and bicycle

reply "Michael" <pr m1xa.com> writes:
hg.m1xa.com/codewithd/commits/d81bfa586c7bd260afc19093fff6e42d66916860

Change-set contains two files: observer.d and event.d
Code is simple.

It would be great if this code will work without rt_... functions.

Any comments?
Oct 11 2013
parent reply "Robert" <jfanatiker gmx.at> writes:
Hmm, are you aware of: https://vhios.dyndns.org/signal.html , 
code at:
https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d

?

Best regards,

Robert

On Friday, 11 October 2013 at 21:28:22 UTC, Michael wrote:

 hg.m1xa.com/codewithd/commits/d81bfa586c7bd260afc19093fff6e42d66916860

 Change-set contains two files: observer.d and event.d
 Code is simple.

 It would be great if this code will work without rt_... 
 functions.

 Any comments?
Oct 12 2013
parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Saturday, 12 October 2013 at 10:41:37 UTC, Robert wrote:

 Hmm, are you aware of: https://vhios.dyndns.org/signal.html , 
 code at:
 https://github.com/phobos-x/phobosx/blob/master/source/phobosx/signal.d

 ?

 Best regards,

 Robert


Do you have any plans to include the code into Phobos? It's look 
like that `std.signal` have `Ready for review` status too long.
I'm sure that Dicebot will be happy to help you as a review 
manager:
http://forum.dlang.org/thread/kiyfunngmuevxjurmjfh forum.dlang.org
Oct 12 2013
parent reply "Robert" <jfanatiker gmx.at> writes:
 Do you have any plans to include the code into Phobos?


Of course! :-) I am just waiting until people have finished 
reviewing all the other good stuff and a review manager is needed 
indeed. It might not be a bad idea to pick it up next, because it 
is just a single module and relatively simple, so review should 
not take too long.

Pushing it a bit might also make sense, because it fixes already 
existing stuff, so it is improving phobos' quality instead of 
just its quantity.

The code seems to be already in use by a number of people, as I 
distill from the feedback and I haven't heard of any issues for 
quite some time now.

I would be glad to have Dicebot as review manager ;-)



Best regards,

Robert

  It's

 look like that `std.signal` have `Ready for review` status too 
 long.
 I'm sure that Dicebot will be happy to help you as a review 
 manager:
 http://forum.dlang.org/thread/kiyfunngmuevxjurmjfh forum.dlang.org
Oct 12 2013
next sibling parent reply "Michael" <pr m1xa.com> writes:
I saw the announcement about new signal some time ago.

D Language is amazing, but in this case it's looks like little 
bit complicated.

I written my code in terms of simplicity: using a standard 
language features and simple design.

In the broadest sense it was a little experiment. As result at 
final stage I have next questions:

- why with this simple task we should use a rt_... magic?
- why rt_... hooks is used like dtors?
- why to write a simple iterator over container and calling its 
data we need above magic?
- if I will see problems in signals implementation, why I need to 
know about "hidden" references that GC not sees?
- what if rt_... or GC behaviour will changed and it's will not 
possible using standard and documented language features in this 
case?
Oct 13 2013
parent reply "Robert" <jfanatiker gmx.at> writes:
 - 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
Oct 13 2013
parent "Michael" <pr m1xa.com> writes:
 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);

 ?


It prevents InvalidMemoryOperationError when in different cases 
observer or observable not destroyed manually;

Also it is was implemented in such way because I can change a 
strategy of event emitting. Yes, may be it was written in 
completely wrong way.

Once again it was an experiment ;)
Oct 13 2013
prev sibling parent reply "ilya-stromberg" <ilya-stromberg-2009 yandex.ru> writes:
On Saturday, 12 October 2013 at 19:25:01 UTC, Robert wrote:

 Do you have any plans to include the code into Phobos?


 Of course! :-) I am just waiting until people have finished 
 reviewing all the other good stuff and a review manager is 
 needed indeed. It might not be a bad idea to pick it up next, 
 because it is just a single module and relatively simple, so 
 review should not take too long.

 Pushing it a bit might also make sense, because it fixes 
 already existing stuff, so it is improving phobos' quality 
 instead of just its quantity.

 The code seems to be already in use by a number of people, as I 
 distill from the feedback and I haven't heard of any issues for 
 quite some time now.

 I would be glad to have Dicebot as review manager ;-)


Great!
Dicebot agree to be your review manager, your turn for a formal 
review will be after Robert Schadek's `std.logger` or, maybe, 
after Jacob Carlborg's `std.serialization`:
http://forum.dlang.org/post/prjjhtrfovxhlvedcnwf forum.dlang.org

You can contact Dicebot via e-mail:
public at dicebot dot lv

I can suggest you:
- improve description (look at the old std.signals, specify if 
module have tread support, add link to the wikipedia and so on)
- add more examples
Oct 13 2013
parent "Robert" <jfanatiker gmx.at> writes:
 I can suggest you:
 - improve description (look at the old std.signals, specify if 
 module have tread support, add link to the wikipedia and so on)
 - add more examples


Thanks, thought about this already. Will do.
Oct 13 2013