Идиоматический способ блокировки асинхронных операций

Question

Я смотрел какой-то проект 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 
} 

есть ли какой-либо преимущество/недостаток для вызова каждого метода с

(неявным например: 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 
} 

Есть ли предпочтительный вариант?

Answer 1

Прежний подход дает вам больше гибкости в отношении того, где будет запланировано выполнение createAsync, поскольку каждый раз, когда вы можете принять решение о том, к какому ExecutionContext вы хотите пройти, вопрос: нужна ли вам такая гибкость? Я нахожу, что в большинстве случаев достаточно одного ExecutionContext, но это действительно вопрос в каждом конкретном случае.

В общем, первый фрагмент ужасен ИМО. Обнаружение синхронной обертки, которая блокирует асинхронную операцию, обычно является признаком запаха кода, и такой код плохо масштабируется.