如何解决scala中的“类型不匹配，预期：_ $ 1，实际：任何”错误？

Question

I have a scenario similar to the following example

// Reads from somewhere and returns List of type A
trait Reader[A]  {
  def read(): List[A]

}

// Transforms element of type A, performs some operation
// and converts result to string
trait Translator[A]  {
  def translate(a: A): String
}



object Factory {

  def getReader(readerName:String) = {

    readerName match {
     case "one" =>  new Reader[String] {
        override def read() = List("sasha")
     }
     case "two" => new Reader[Int] {
        override def read() = List(3)
     }
     case _ => throw new IllegalArgumentException
   }

 }

 def getTranslator(translatorName:String) =  {

   translatorName match {
     case "one" => new Translator[String] {
        override def translate (a: String) = a + " " + "nice!!!"
     }
     case "two" => new Translator[Int] {
        override def translate(a: Int) = (a+2).toString
     }
     case "three" => new Translator[Int] {
        override def translate(a: Int) = (a+3).toString
     }
     case _ => throw new IllegalArgumentException
   }
 }

}

Now when I do Factory.getReader("one").read().map(a => Factory.getTranslator("one").translate(a)) , I get a compile time error "Type mismatch, expected: _$1, actual: Any".

If I am not wrong, compiler is saying it can't tell if the type A of reader is same as type A of translator.

I am unable to find online, how I can get around this problem ? Am I doing something fundamentally wrong in defining the classes the way I have ?

EDIT

Reason I have separate reader and translator is that, they seem to have different jobs, and I could apply more than one translator to the output of one reader (translator 2 and 3 above can be applied to output of reader 2).

Answer 1

The trouble with your approach is that you've defined a couple methods in which you want to return a different type depending on your input, but that input doesn't have any type information for the compiler to work with.

Ie your getReader function needs to act as both a String => Reader[String] and a String => Reader[Int] depending on the value (not type !) of the input. The compiler tries to figure out the common type between those two cases and comes up with String => Reader[Any] , but then when you try to use that, the loss of the specific type information becomes a problem.

I think the best solution to this is to introduce a type parameter on the input side of your method, eg

case class ReaderName[T](name: String)

// these would be defined as constants on an object somewhere
val ReaderOne = ReaderName[String]("one")
val ReaderTwo = ReaderName[Int]("two")

def getReader[T](readerName: ReaderName[T]): Reader[T] = readerName match {
  case ReaderOne => new Reader[String] { ... }
  case ReaderTwo => new Reader[Int] { ... }
  case _ => throw ...
}

The point here is that you're attaching type information to a name in the form of the [T] argument on ReaderName . That type information can be used by the compiler to ensure you get a Reader instance for the appropriate T type based on the ReaderName you pass in.

Note that you shouldn't try do this:

getReader(ReaderName[Int]("one")) // no!

because it will likely match ReaderOne despite having the wrong type parameter (thanks to type erasure on the JVM), and you'll run into ClassCastExceptions down the road. You should be defining ReaderName instances as constants, and referencing those constants.

A similar approach would be to define the ReaderNames as a sealed trait/abstract class; doing so would allow you to avoid having to throw IllegalArgumentExceptions, and would help protect against the "no!" example above.

sealed abstract class ReaderName[T](val name: String)
object ReaderName {
  case object One extends ReaderName[String]
  case object Two extends ReaderName[Int]
}

def getReader[T](name: ReaderName[T]): Reader[T] = readerName match {
  case ReaderName.One => new Reader[String] { ... }
  case ReaderName.Two => new Reader[Int] { ... }
  // no need for a `case _` becase ReaderName is sealed and we have handled all cases
}