我认为这通常是不可能的,因为参与者可以在运行时改变其行为,包括它可以处理的消息——而不是可以静态索引的方法。例如,可以根据参与者状态计算接收函数:
class MyActor extends Actor {
var i = 0
def receive = firstReceive
def commonReceive = {
case Increment =>
i += 1
if (i % 3 == 0) context.become(firstReceive)
else context.become(secondReceive)
}
def firstReceive = commonReceive orElse {
case Ping =>
sender ! "zero"
}
def secondReceive = commonReceive orElse {
case Ping =>
sender ! "one or two"
}
}
现在,actor 处理消息的方式不同,具体取决于它之前处理的消息。这只是一个简单的例子——甚至可能从外部接收到实际的actor行为!
case class Behavior(receive: Actor.Receive)
class MyActor extends Actor {
def receive = {
case Behavior(r) => context.become(r)
}
}
另一个更大的困难是,您通常有一个ActorRef
用于发送消息的地址!
。这ActorRef
与包含消息处理逻辑的actor类没有静态连接 - 它被实例化Props
,可以使用任意代码来确定应该使用哪个actor类:
val r = new Random
val a = actorSystem.actorOf(Props(if (r.nextInt(100) > 50) new FirstActor else new SecondActor))
a ! Message // which handler should this declaration lead to?
这使得几乎不可能找到实际的消息处理程序。
如果您认为支持更简单的案例(例如您提供的案例)可能值得,您可以随时向YouTrack提交功能请求。