Scala 为什么不是'；不要直接问阿克卡的ActorRef？

我正在学习Akka，在探索API的过程中，我发现了一些奇怪的东西（至少对我来说是这样）。

tell

函数直接在ActorRef类上定义。但是，

ask

函数是在AskSupport特性中声明的。我想不出有什么好的理由，为什么他们需要为

AskSupport

提供一个单独的特性，而不是在ActorRef的API中包含

ask

（以及在ScalaActorRef的API中包含

？

）。有人愿意告诉我这背后的原因吗？

根据：

使用

ask

会对性能产生影响，因为 需要跟踪它何时超时，需要一些东西 它将

承诺

连接到

ActorRef

中，并且它还需要 可通过远程处理访问。因此，对于性能，请始终选择

tell

， 如果必须的话，只询问

有鉴于此，您可以通过要求用户显式导入工具来巧妙地阻止使用
ask
。这还可以减少ActorRef API中的膨胀。
请记住，Akka基于actors的Erlang系统，我相信
tell
是该系统中Actor之间进行通信的唯一工具。我想Akka的伙计们想让Akka中的ActorRef

尽可能类似于Erlang模拟

---

要记住的另一件事是，

ask

只是一种使用

tell

的模式，然后设置一个

Future

和临时参与者来处理响应的

tell

，使其看起来像本地请求/响应过程。但在幕后，实际上只是两个演员在相互讲述。这是一种使用

tell

s创建请求/响应外观的惯例，这就是为什么它在Akka中设置为一种模式，可以在需要时拉入，而不是作为

ActorRef

的一部分。Actor文档给出了作者的推理：

ask模式涉及参与者和未来，因此它是作为使用模式而不是ActorRef上的方法提供的

ask模式包括将来的扩展，而不仅仅是ActorRef扩展。特别是，如果您查看akka.pattern文档，您会注意到，

PipeToSupport

和

PipeableFuture

超出了对akka对象的扩展。

对于（现在已弃用的）Scala参与者来说也是如此。Akka最初被命名为scala otp，其灵感来源于Erlang等效物，这也是事实。然而。。。Akka的模式现在与Erlang的模式有了很大的不同；最值得注意的是，关于嵌套接收的处理。Akka还集成了许多参与者之上和之外的并发模式。因此，在这两种实现之间进行类比不再严格正确。