Quiero escribir una función que se comporte de manera diferente según su parámetro de tipo. Un simple ejemplo de lo que quiero se muestra a continuación:¿Puedo especializar los parámetros de un tipo de funciones en Scala como puedo con la especialización de plantilla C++?
def f[Int] = "I'm an int"
def f[Float] = "I'm a float"
def f[Burger] = "You want fries with that?"
Es esto posible en Scala o necesito algún tipo de trabajo en torno a?
No directamente; la forma habitual en que harías esto en Scala es con una clase de letra.
trait FAble[T] { def doF: String }
object FAble {
implicit val fInt = new FAble[Int] { def doF = "I'm an int" }
implicit val fFloat = new FAble[Float] { def doF = "I'm a float" }
implicit val fBurger = new FAble[Burger] { def doF = "You want fries?" }
}
def f[T](implicit ev: FAble[T]) = ev.doF
// or
def f[T: FAble] = implicitly[FAble[T]].doF
Es un poco justo más prolija, pero tiene algunas ventajas también - los casos implícitos pueden ser calculados (utilizando implicit def s en lugar de val s), y no puede haber más de una instancia de cualquier tipo dado , que le permite seleccionar el comportamiento en tener distintas instancias en el alcance en diferentes puntos del código.
La razón por la que no puede hacerlo de la forma de C++ es que los genéricos Scala no implican la generación de código para los diferentes parámetros de tipo-(@specialized un lado, ya que no hace lo que quiere tampoco). Por lo tanto, no tiene sentido decir "hey compiler", cuando vea un "Int" en esa posición, en lugar de generar el código que usaría de la plantilla genérica, use este código específico en su lugar ".
Es posible que desee buscar en las macros: http://scalamacros.org/. Las macros son funciones personalizadas que se ejecutan durante la compilación y pueden generar códigos dinámicamente en función de los cálculos en tiempo de compilación.
Otro enfoque posible es que utilice evidencias:
def f[T](t:T)(implicit ev: T<:<Float) {
// float version
}
def f[T](t:T)(implicit ev: T<:<Int) {
// int version
}
Sin embargo, recomendaría el tipo clases como una solución mucho más elegante