ComposableActor example

[Rich Dougherty]

Hi devs

As I'm writing the ComposableActor example (docs, bug, PR) I'm beginning to suspect that it's not a good example of how actors' behaviour should be composed together. Combining behaviour from subclasses together in a mutable data structure seems fragile, because of initialisation order issues, e.g. if two traits add behaviour for "foo", which one will will be registered first and which one will execute?

We actually made an initialisation order mistake in our original example too by registering receive behaviours in preStart which occurs after receive is called, resulting in no behaviour at all. We had a different bug in 2.0 because we misunderstood the order of variable initialisation and receive was called when the list of handlers was still null, causing a NPE. Endre suggested fixing the final PartialFunction with become at construction time, but that also raises the complex question of initialisation ordering at construction time. Anyway, I'm sure you get the idea!

I'm starting to think there's a high chance of mistakes when using this pattern.

I much prefer the example above* which uses normal methods to do its work, and which will be statically verified.

What do you guys think?

Cheers

Rich

* Although I'd make a couple of changes to the other example too: make receive a val, and make genericMessageHandler final. :)

[Jonas Bonér]

I don't think we should recommend something this fragile. People will do it anyway, but then we have at least not recommended them to go down that route. 

--
You received this message because you are subscribed to the Google Groups "Akka Developer List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jonas Bonér
Phone: +46 733 777 123
Home: jonasboner.com
Twitter: @jboner

[Rich Dougherty]

I created a ticket: https://www.assembla.com/spaces/akka/tickets/3102