Actor Styles... OO, Functional or Blended...

I had the privilege of a free cup of coffee with David Pollak when I was in the bay area recently. He was describing his new goat-rodeo library when he showed me the interface for his "Worker" class (which is similar to an Actor class). He made a comment about "being annoyed with writing all those case statements" in actors, and so figured out a method using reflection and method overloading to define an actor that merely responds to all messages it receives. I'm sure there was more to it than this, but I believe he's partially solved an OO issue I complained about in an earlier blog about partial functions and inheritance. Let's take a bit to remember that solution to the issue.

The crux of the problem is the blend of OO and functional. Functions are composable. You can have one function take another and compose them all day long. Objects are also composable. One object can take another object and utilize it all day long. Methods (functions attached to objects) are not as composable. Scala traits give you means to compose with them, but all your composition is done at instantiation time (i.e. mixing in traits, inheritance, etc.). Now we come to the main issue. An Actor is an abstract class that you subclass. This leads one to compose behavior through traits (similar to other OO-style programs in Scala), but the method of doing so is a bit strange. We start with our "FinalMixinActor" class

trait BaseActor extends Actor {

   def makeMessageHandler() : PartialFunction[Any,Unit] = {
      case x => //Unhandled message, assume design flaw!
            error("Unknown message: " + x)    
   }
}
trait FinalActor extends BaseActor[T] {
   lazy val messageHandler = makeMessageHandler()
   override def act() {
       Actor.loop {
          react messageHandler
       }
   }
}

These two classes provide us with a way to compose actors. We make sure all behavior extends the BaseActor, and we make sure when creating an actor that "FinalActor" gets mixed in *last* in the inheritance linearization. This means that when FinalActor calls "makeMessageHandler", all the standard OO inheritance has a chance to kick and pull the behaviors you've composed. Let's see an example of composing an actor with two functionalities....

case class Ping()
case class Pong()

trait PingPongBehavior extends BaseActor {
   def makeMessageHandler() : PartialFunction[Any,Unit] = {
      val myBehavior : PartialFunction[Any,Unit] = {
         case Ping() => sender ! Pong()
      }
      return myBehavior orElse super.makeMessageHandler()
   }
}

This is our "PingPong" behavior actor for sending/receiving Ping/Pong messages. As you can see in the makeMessageHandler... we're manually converting functional composition into inheritance composition. It does give us flexibility if we'd like our behavior to run last. Let's create our second piece of behavior...

case class Shutdown()

trait RemoteControlBehavior extends BaseActor {
   def makeMessageHandler() : PartialFunction[Any,Unit] = {
      val myBehavior : PartialFunction[Any,Unit] = {
         case Shutdown() => Actor.exit
      }
      return myBehavior orElse super.makeMessageHandler()
   }
}

This is a simple actor that just lets us send a shutdown command to an actor instead of relying on the actor knowing when to shut itself down (or linking it). Not necessarily useful, but it will help illustrate our next point. Let's create an actor that mixes in both these functionalities.

val myActor = new PingPongBehavior with RemoteControlBehavior with FinalActor
myActor.start

Notice how we *have* to mix in FinalActor last so the composition of makeMessageHandler is done correctly. This also prevents other actors from adding behavior in their act methods....

Anyway, it's a decent method of allowing mixin behavior of actors. It doesn't have much type safety, but the Scala standard actors library actually makes you jump through some hoops to get type-safety anyway (plus all their samples are against Any... so it seems they tend to encourage this...)


Now for a look at how Goat-Rodeo helps solve this. First, Goat-Rodeo uses a type-safe message passing API, including knowing whether a message is allowed a response, and the type of that response. Let's take a look at a boiled down version of the twitter-clone sample on goat-rodeo's wiki. I've used elipses to ignore implementation details of Goat Rodeo:

class UserWorker(...) extends WorkerImpl[..., UserMsg](...) {
  /**
   * handle the Follow message
   */
  def doFollow(msg: Follow) {
     ...
  }
}

As you can see, it's just a method. Goat-Rodeo looks for methods with "do" or "handle" in the name and constructs a PartialFunction for the actor-behavior. The

Follow

class must be a subclass of

UserMsg

as Goat-Rodeo is also strongly typed. Because

doFollow

returns Unit, goat-rodeo knows that there is no return expected with this message. If you'd like to handle different messages, simple use method overloading. The best part, if we'd like to use OO inheritance to compose behavior, we can do so directly now...

class UserWorkerPlus(...) extends UserWorker(...) {
  /**
   * handle the Follow message
   */
  def doFollow(msg: Follow) {
     println("ZOMG!!!!!!!!!!!!!!!!!!")
     super.doFollow(msg)
  }
}

That should be a lot more comfortable to OO developers. With some type trickery you could even create the "management" behavior traits and mix them into "workers" as needed. It still leaves some things to be desired. e.g. when I compose partial functions in a purely functional sense, I can have the type-checker automatically infer what the new signature of a partial function should be after an orElse. With both of these methods, that is not possible. For the pure functional users, I'd recommend creating actors using something akin to this function (or you should just use scalaz, as their actors library is very well done):

import scala.actors.Actor
import scala.actors.Channel

class ChanneledActor[T](f : PartialFunction[T,Unit]) extends Actor {
  val typedChannel = new Channel[T](this)
      def act() {
         Actor.loop {
            typedChannel react f
         }
      }
}

def makeActor[T, U](f : PartialFunction[T,U]) : Channel[T] = {
   val a = new ChanneledActor(f andThen ( x => () ))  //Ignore results...
   a.start
   a.typedChannel
}

This will let you compose partial functions in a functional style and let the type-checker figure out the signature. Finally when you create an Actor with the makeActor method, it will return the type-safe channel to send messages with. Here's an example interpreter session:

scala> makeActor[Int,Unit] { case x : Int => println("HAI") }                   
res3: scala.actors.Channel[Int] = scala.actors.Channel@154f77b

scala> res3 ! "HAI"
<console>:10: error: type mismatch;
 found   : java.lang.String("HAI")
 required: Int
       res3 ! "HAI"
              ^

scala> res3 ! 5    

scala> HAI

Anyway, if you truly desire a functional approach to actors, you should look into Scalaz, as they've done it right. If you desire a hybrid or an OO approach, I hope I've helped outline the details for you. I'm very interested to see how all these libraries evolve over time, and kudos to David Pollak for goat-rodeo.