To naprawdę denerwujące, gdy piszesz bardzo silnie współbieżny kod z reakcją Futures lub Actors i ręcznie importujesz ExecutionContext.Implicits.global
. Próbowałem znaleźć dobre wyjaśnienie, dlaczego nie został on ustawiony jako parametr domyślny, tak jak jest done z Strategy
w Scalaz Concurrent
. Byłoby to bardzo pomocne, aby nie wstawiać/nie usuwać całego importu z kodu. Czy może brakuje mi jakiejś logiki?Dlaczego globalny ExecutionContext nie jest parametrem domyślnym w przyszłym bloku?
6
A
Odpowiedz
10
Wydaje się, że ogólny trend wymaga od użytkownika wyraźnego importowania rzeczy takich jak implicity, dodatkowe operatory lub DSL. Myślę, że to dobrze, ponieważ sprawia, że rzeczy są mniej "magiczne" i bardziej zrozumiałe.
Ale nic nie stoi na przeszkodzie, aby zdefiniować niejawną wartość kodu dla całego pakietu. Zauważ, że jeśli niejawny ExecutionContext był zawsze importowany domyślnie, nie byłbyś w stanie tego zrobić.
W obiekcie pakiet:
package object myawsomeconcurrencylibrary {
implicit def defaultExecutionContext = scala.concurrent.ExecutionContext.global
}
W każdej klasie w tym samym opakowaniu:
package myawsomeconcurrencylibrary
object Bla {
future { ... } // implicit from package object is used unless you explicitly provide your own
}