阻止异步操作的惯用方法答案

【问题标题】：idiomatic way to block async operations阻止异步操作的惯用方法
【发布时间】：2017-01-31 14:51:34
【问题描述】：

我正在查看一些开源 scala 项目。我看到有些人正在做类似的事情：

abstract class Foo{

def create(implicit ex: ExecutionContextExecutor): Seq[ResultSet] = {
    Await.result(createAsync(), timeout)
  }

  def createAsync()(implicit ex: ExecutionContextExecutor): Future[Seq[ResultSet]] = //implementation

... more like those 
}

用

调用每个方法有什么好处/坏处吗

(隐式 ex: ExecutionContextExecutor) 参数而不是在类构造函数中传递 ExecutionContextExecutor：

abstract class Foo(implicit ex: ExecutionContextExecutor){

def create(timeout: FiniteDuration): Seq[ResultSet] = {
    Await.result(createAsync(), timeout)
  }

  def createAsync(): Future[Seq[ResultSet]] = //implementation

... more like those 
}

有首选吗？

【问题讨论】：

你能改一下标题吗？这是一个真正的问题，它将使该语言的新手受益，但我来到这里是因为标题读起来就像它主要是一篇评论文章。或者我只是因为我在这里太久而读得太多了......？
@wheaties 你有什么建议？
不知道，“ExecutionContext 应该在方法还是对象上？”听起来也很有主见。 “ExecutionContext 对方法与对象的好处？”嘎……

标签： scala akka

【解决方案1】：

前一种方法使您可以更灵活地安排createAsync 的执行时间，因为每次您都可以决定要传入哪个ExecutionContext。问题是，您是否需要灵活性？我发现大多数时候单个ExecutionContext 就足够了，但这实际上是逐案分析的问题。

一般来说，第一个 sn-p 是可怕的 IMO。暴露一个阻塞异步操作的同步包装器通常是代码异味的标志，这样的代码不能很好地扩展。

【讨论】：

我猜你的意思是第一个选项更灵活，因为 executionContext 在每个 call 中作为参数传递。我不会认为这是代码异味，因为它们为您提供了阻塞调用的选项
@igx 对异步操作的阻塞调用无法扩展。我个人不喜欢看到这样的代码。
我刚刚在大型开源项目中看到了 phantom github.com/outworkers/phantom/blob/…