On Feb 23, 10:12 pm, zixzigma <[email protected]> wrote: > what do you think about support for Asynchronous/Event Driven communication > between objects ? > do you use this technique in your development ? what framework do you use, > and does it make sense to add this to Guice ?
I like asynchronous message-passing style very much. Compared to shared-state concurrency, message-passing avoids many sources of concurrency bugs: the only objects which need to be thread-safe are the message queues and similar infrastructure. In my most recent message-passing based project I'm using Scala, because Scala's pattern matching and case classes makes it very easy to create and handle the messages (my next project will be in Java, and there I will probably use a bit different style because Java has no pattern matching). I decidedly avoided using Scala's actor library and instead created my own Actor library (it's very simple to do), in order to have it simpler and more predictable, because in that project reliability is of high importance. I have created abstract Guice module base class for wiring the actors and keeping them isolated, though it is pushing the limits of what is reasonable to do with Guice (<https://github.com/orfjackal/dimdwarf/blob/master/dimdwarf-core/src/ main/java/net/orfjackal/dimdwarf/actors/ActorModule.java> <https:// github.com/orfjackal/dimdwarf/blob/master/dimdwarf-core/src/main/java/ net/orfjackal/dimdwarf/modules/ActorInstallerModule.java> <https:// github.com/orfjackal/dimdwarf/blob/master/dimdwarf-core/src/main/java/ net/orfjackal/dimdwarf/actors/ActorStarter.java>; example usage <https://github.com/orfjackal/dimdwarf/blob/master/dimdwarf-core/src/ main/java/net/orfjackal/dimdwarf/modules/AuthenticatorModule.java>). I did a spike on wiring the actors manually, and it produced a much simpler solution with not much more boilerplate per actor (<https:// github.com/orfjackal/dimdwarf/blob/manual-di-spike/dimdwarf-core/src/ main/scala/net/orfjackal/dimdwarf/server/ManualDISpike.scala>). I don't think that adding something like a concurrency model to Guice makes sense. There are too many ways in which it could be done and one size would not fit all. It might make sense as a separate library which depends on Guice. -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
