When to use implicit parameters-CodePudding

I've been using Scala at work, and I have a question related to implicit parameters.

Often I've seen executionContext defined in method definitions and also in class definitions. At the same time I've seen classes that accepts case classes that contain configuration data (timeout, adapter, port, etc.) as regular parameters.

My question is why when passing configuration this parameter is not defined as implicit? Or the other way around what if executionContext would be defined as a regular parameter? I'm trying to understand when to use implicit parameter and when not to use them.

EDIT: maybe the example of passing a case class is not the best example, it was the first idea that comes to my mind

CodePudding user response：

Conceptually, implicits are something "external" to the application logic, and explicit parameters are ... well ... explicit.

Consider a function def f(x: Double): Double = x*x It is a pure function that transforms a given real number into another real number. It makes sense for x to be an explicit parameter, as it is an intrinsic part of what this function is.

Now, suppose, you were implementing some sort of approximate algorithm for multiplication, and wanted to control the precision with which you function computes the answer. You could do def f(x: Double, precision: Int): Double = ???. It would work, but is inconvenient and kinda clumsy:

Function definition no longer expresses the conceptual "nature" of the function being a pure transformation on the set of real numbers
It makes it complicated at the call site, because everyone using your function must now be aware of this additional parameter to pass around (imagine, you are writing a library for non–engineer math majors to use, they understand abstract transformations and complex formulas, but could care less about numeric precision: how often do you think about precision when you need to compute an area of a square?).
It also makes existing code harder to read and modify

So, to make it prettier, you can do def f(x: Double)(implicit precision: Int) = ???. This has an advantage of saying exactly what you want: "I have a transformation double => double, that will use the implied precision when the actual result is computed). Those math majors can now write their abstract formulas the way they are used to: val area = square(x) without polluting their logic with annoying configurations they don't really care about.

When to use this exactly is, certainly, a question of opinion and taste (which is expressly forbidden on SO). Someone can certainly argue about the above example, that precision is actually a part of the transformation definition, because 5.429 and 5.54289 (results of f(2.33)(3) and f(2.33)(4) respectively) are two different numbers.

So, in the end of the day, you just gotta use your judgement and your common sense to make a decision for every case you come across.

When using existing libraries, there is another consideration. Consider:

    def foo(f: Future[Int], ec: ExecutionContext) = 
       f.map { x => x*x }(ec)
        .map { _.toString } (ec)
        .foreach(println)(ec)

This would look a lot nicer and less messy if you made ec implicit, regardless of where you stand philosophically on whether to consider it a part of your transformation or not:

     def foo(f: Future[Int])(implicit ec: ExecutionContext) = 
        f.map { x => x*x }.map(_.toString).foreach(println)

CodePudding user response：

Implicits can be used when:

you need only one value of some type
it is unambiguous how such value would be defined
- this includes both manual definition as well as using metaprogramming to generate the value based on e.g. how its type is defined

Futures and Akka decided that passing some "globals" as implicits is a reasonable use case, so they would pass as implicits:

ExecutionContext
ActorSystem, Materializer
various configs like Timeout

in general things which you don't want to be put into some static field, but which are passed around everywhere.

However, the rest of Scala world would solve this issue by using some abstraction that would pass these things under the hood, some sort of builders, via constructors, abstractions over (dependencies) => result functions, etc.

E.g. cats.effect.IO don't need to pass ExecutionContext around because it passes its scheduler around when you run it. Only when you want to explicitly change the pool things are being run on you have to use some method. In Monix running things also require you to pass Scheduler at the end, when whole computation is composed. So both approached let you give up on passing around all these ExecutionContexts. In case of Future it is necessary because you need to have control over thread pools, but you also evaluate things eagerly, and putting ec (futureA.flatMap(f)(ec)) manually would break for-comprehension.

As a result, outside Akka ecosystem and raw Futures, are more often used to carry around type-classes, as a mean to decouple business logic from particular implementation, allow adding support for new types without modifying code that uses these implementations, and so on. (There are tons of examples of type-classes in Scala so I'll skip it here).

Usually, when I read about people using implicits to pass configs around, it is just a matter of time before it ends up with grief. Akka and EC kind of requires them but you should just pass configs explicitly. You can group them into case classes to pass bunch of them around and it is not that much of an issue. You can also put all things required as implicits explicitly into one place and do:

case class Configs(dbEX: EC, mapEC: EC)
class SomeBehavior(configs: Configs) {

  def someAction = {
    if (...) {
      implicit val ec: EC = configs.dbEC
      ...
    } else {
      implicit val ec: EC = configs.mapEC
      ...
    }
  }
}

to make them implicit only in the place that needs them. A good role of thumb is: do you care if there is something passed around that you don't see right in the code? Usually, the answer is, yes you do, you would prefer to see it, with only exceptions being cases when it would be somewhat obvious where does the value come from, or if you kinda knew that the value would be ok and you didn't bother where it came from.

CodePudding user response：

There are a multitude of use-cases of implicit in Scala: under the hood, they boil down to leveraging the compiler's implicit resolution mechanism to fill in things that might not have explicitly been mentioned, but the use-cases are divergent enough that in Scala 3, each use-case (of those that survive into Scala 3...) gets encoded with a different keyword.

In the case of the execution context, implicit arguments are being used to mimic dynamic scope in a language which is normally statically scoped. The primary win from doing this is that it allows behavior further down the call stack to be decided-upon much further up the call stack without having to always explicitly pass on the behavior through the intervening layers of the stack (while providing a way for those intervening layers to cleanly force a different behavior).

Historically, a major example of this was for things like numeric precision. Many numeric operations end up being implemented through iterated refinement (e.g. when square-root was implemented in software, it might be implemented using Newton's method), which means there's a trade-off between speed of calculation and precision (suggesting accuracy). With dynamic scoping, there's a neat way to accomplish this: a global variable for the desired level of precision in mathematical results. Your numeric routine checks the value of that variable and governs itself accordingly. The difference from globals in a statically-scoped language is that when A calls B which calls C, if A sets the value of x to 1 and B sets it to 2, x will be 2 when checked in C or B, but once B returns to A, x will once again be 1 (in dynamically scoped languages, you can think of a global variable as really being a name for a stack of values, and the language implementation automatically pops the stack as appropriate).

Dynamic scoping was once fairly popular (especially so in Lisps before the mid/late 1970s); nowadays the only places you really see it are in Bourne shells (including bash), Emacs Lisp; while some languages (Perl and Common Lisp are probably the two main examples) are hybrids: a variable gets declared in a special way to make it dynamically or statically scoped. Static scoping has pretty clearly won: it's easier for the language implementation or the programmer to reason about.

The cost of that ease is that, in our numeric computation example, we end up with something like the following:

def newtonSqrt(x: Double, precision: Int): Double = ???

/** Calculates the length of the hypotenuse of a right triangle with legs of given lengths
 */
def hypotenuse(x: Double, y: Double, precision: Int): Double =
  newtonSqrt(x*x   y*y, precision)

Thankfully, Scala supports default arguments, so we avoid having versions that use a default precision, too. Arguably, the precision is exposing an implementation detail (the fact that our calculations aren't necessarily perfectly mathematically accurate): the important thing is that the length of the hypotenuse is the square root of the sum of the squares of the legs.

In Scala, we can make the precision implicit:

// DON'T ACTUALLY PASS AN INT IMPLICITLY!!!!!!
def newtonSqrt(x: Double)(implicit precision: Int): Double = ???

def hypotenuse(x: Double, y: Double)(implicit precision: Int): Double =
  newtonSqrt(x*x, y*y)

(It's actually really bad to ever pass a primitive or any type which could plausibly be used for something other than describing the behavior in question through the implicit mechanism: I'm doing it here for didactic clarity).

The compiler will effectively translate newtonSqrt(x*x y*y) to (something very similar to) newtonSqrt(x*x y*y, precision). Now callers to hypotenuse can decide to fix precision via an implicit val or to defer the choice to their callers by adding the implicit to their signature.

Dynamic scoping has long been controversial, so it's no surprise that even the constrained dynamic scoping this usage of implicit embeds is controversial. In Scala's case, it doesn't help that in many cases the tooling throws up its hands when it comes to helping you figure out implicits: most of the really furious compiler errors one encounters are related to missing implicits or collisions, and tracing to figure out which values are in the implicit scope at any time is not something the tooling has a history of helping people with. Thus there are many developers who have decided that explicitly threading through configuration is superior to using implicits.

It's largely a matter of taste and the situation whether this sort of behavior description is best passed implicitly or explicitly (and it's worth noting that the type-class pattern, especially without a hard requirement for coherence (that there be one and only one possible way to describe the behavior) as is typical in Scala, is just a special case of this behavior description).

I should also note that it isn't a binary choice between bundling a few settings into a case class vs. passing them implicitly: you can do both:

case class ProcessSettings(sys: ActorSystem, ec: ExecutionContext)

object ProcessSettings {
  implicit def implicitly(implicit sys: ActorSystem, ec: ExecutionContext): ProcessSettings =
    ProcessSettings(sys, ec)
}

def doStuff(x: SomeInput)(implicit settings: ProcessSettings)