具有隐式参数的泛型函数

Question

I have a situation where I am trying to create a generic function which should be able to take any instance of a class which specifies a certain implicit value in its companion object. I have replicated my problem below:

// Mocking up the library I am working with
trait Formatter[A] {
    def output(o: A): String
    def input(s: String): A
}


// Some models
trait Human

case class Child(name: String) extends Human
object Child {
    implicit val f: Formatter[Child] = new Formatter[Child] {
        override def output(c: Child): String = { ... }
        override def input(s: String): Child = { ... }
    }
}

case class Teen(name: String) extends Human
object Teen {
    implicit val f: Formatter[Teen] = new Formatter[Teen] {
        override def output(t: Teen): String = { ... }
        override def input(s: String): Teen = { ... }
    }
}


// The generic function
def gen[A <: Human](a: A)(implicit format: Formatter[A]) = {
    // Do something with a formatter...
}

---

This all works fine, I can pass an instance of a Child or a Teen to my gen function:

gen(Child("Peter"))
gen(Teen("Emily"))

---

What I am having trouble with is that at run time I only know that the instance I am passing will be a subtype of a Human :

// Example of unknown subtype
val human: Human = Random.nextBoolean match {
    case true => Child("Peter")
    case false => Teen("Emily")
}

gen(human)  // Error: Could not find implicit value for parameter format...

I understand that the error is because Human has no companion object and therefore it has no implementation of a Formatter .

How can I add a constraint to Human that says "anything extending Human will implement a new Formatter" ?

Answer 1

You don't need implicits for this. Just make your subclasses point to the implementation directly:

trait Human[+A <: Human] {
 def formatter: Formatter[A]
}

case class Child(name: String) extends Human[Child] {
 def formatter = Child.f
}

// etc
def gen[A <: Human](a: A) {
   // do something with a.formatter 
}

Of course, Formatter needs to be covariant in A too. Otherwise, all bets are off: you simply cannot do what you want - there is nothing useful gen could do with it without knowing the specific type anyway.

If specifics of the concrete type are not needed in gen, you can still use implicits by enumerating them explicitly like this (but I don't really see why you would want that):

 object Human {
    implicit def formatter(h: Human): Formatter[_] = h match {
      case Child(_) => Child.f
      case Teen(_) => Teen.f
    }
 }

 gen(h: Human)(implicit f: Formatter[_]) { ... }

Like I said, this does not seem very useful though, so not sure why you want want this over the above approach.

Answer 2

Your scenario fails because you should implement a Formatter[Human]. I think that what you want is that all the Human should be able to have this format "capability" instead.

At this point you have two options, one is to include in the Human trait a method for formatting (this implementation could be in the object if you want it static) or try a dsl approach where you will create a class with the responsibility to provide humans a new capability: "format".

The first approach could be something like this:

trait Human { def format:String }

case class Child(name: String) extends Human {
  import Child._
  override def format = Child.staticFormat(this)
}

object Child {
  def staticFormat(c: Child): String = s"Child(${c.name})"
}

However I think "format" shouldn't be in the contract "Human" so I prefer the second approach:

trait Human

case class Child(name: String) extends Human

case class Teen(name: String) extends Human

import scala.language.implicitConversions

class HumanFormatter(human: Human) {
  def format: String = human match {
    case c: Child => s"Child(${c.name})"
    case t: Teen => s"Teen(${t.name})"
  }
}

object HumanDsl {
  implicit def humanFormatter(human: Human): HumanFormatter = new HumanFormatter(human) 
}

object Test extends App {
  def human: Human = Random.nextBoolean match {
    case true => Child("Peter")
    case false => Teen("Emily")
  }

  import HumanDsl._

  for(i <- 1 to 10) println(human.format)
}

What are the differences between both solutions? In the first one you force all the new Human classes to implement a format method so you can assure that your code will work always. But at the same time... you are adding a Human a method that from my point of view is not necessary, I think a case class should have only the information needed and if you need to format/parse that class then is better to add this functionality just when needed (dsl approach).

In the other hand, with dsl you should update the formatter anytime a new Human class is created. So it means that the human.format method above will fail if a new Human class is created (you can always match _ to do a default behaviour or raise a custom error).

I think is a matter of design, I hope this would help you a little bit.

---

Edited:

just like a comment showed the Human trait could be sealed to ensure that the HumanFormatter pattern match doesn't compile if some class is not covered.