¿Por qué reemplazar mi clase de caja Scala con un extractor rompió mi función de orden superior?

Question

Supongamos que tengo una clase de caso simple que envuelve enteros, y un método de orden superior que acepta una función que transporta enteros a envoltorios.

case class Wrapper(x :Int) 
def higherOrder(f : Int => Wrapper) = println(f(42)) 

Luego, puedo llamar a la función de orden superior, pasando la función de aplicación generada del contenedor. Sorprendentemente, también puedo pasar el nombre del envoltorio.

higherOrder(Wrapper.apply) // okay 
higherOrder(Wrapper)  // okay, wow! 

Esto es realmente genial. Nos permite tratar el nombre de la clase de caso como una función, que fomenta abstracciones expresivas. Para ver un ejemplo de esta frialdad, mira la respuesta aquí. What does "abstract over" mean?

Supongamos que mi clase de caso no es lo suficientemente potente, y necesito crear un extractor en su lugar. Como un caso de uso levemente artificial, digamos que necesito poder hacer coincidir patrones en cadenas que se convierten en enteros.

// Replace Wrapper case class with an extractor 
object Wrapper { 
    def apply(x :Int) = new Wrapper(x) 
    def unapply(s :String) :Option[Wrapper] = { 
     // details elided 
    } 
} 
class Wrapper(x :Int) { 
    override def toString = "Wrapper(" + x + ")" 
    // other methods elided 
} 

Bajo este cambio, todavía puedo pasar Wrapper.apply en mi función de orden superior, pero al pasar en tan sólo Envoltura ya no funciona.

higherOrder(Wrapper.apply) // still okay 
higherOrder(Wrapper)  // DOES NOT COMPILE 
      ^^^^^^^ 
// type mismatch; found : Wrapper.type (with underlying type Wrapper) 
// required: (Int) => Wrapper 

Ouch! He aquí por qué esta asimetría es preocupante. El consejo de Odersky, Spoon y Venners (Programación en Scala, página 500), dice

Siempre puede comenzar con las clases de casos y luego, si es necesario, cambiar a los extractores. Debido a que los patrones sobre los extractores y los patrones sobre las clases de casos se ven exactamente iguales en Scala, las coincidencias de patrones en sus clientes continuarán funcionando.

Muy cierto, por supuesto, pero romperemos a nuestros clientes si están utilizando nombres de clases de casos como funciones. Y como hacerlo permite abstracciones poderosas, algunos seguramente lo harán.

Por lo tanto, al pasarlos a funciones de orden superior, ¿cómo podemos hacer que los extractores se comporten de la misma manera que las clases de casos?

Answer 1

Scala objetos extractora de compañía deben extenderse Función

Para las clases de casos, el compilador genera un objeto acompañante bajo el capó. Esto contiene métodos estáticos relevantes para la clase de caso Wrapper, incluido apply. Observando el bytecode, descubrimos que el objeto complementario de Wrapper se extiende a Function1. (En realidad, se extiende AbstractFunction1, que usa @specialized para obviar el autoboxing.)

Esto también se menciona aquí. Why do case class companion objects extend FunctionN?

Cuando reemplacemos nuestra clase de estuche Wrapper con un extractor, debemos tener cuidado de ampliar nuestro objeto compañero de fabricación casera con AbstractFunction1 para preservar la compatibilidad con versiones anteriores para nuestros clientes.

Esto representa una pequeña modificación en el código fuente. El método de aplicación no cambia en absoluto.

object Wrapper extends scala.runtime.AbstractFunction1[Int, Wrapper] { 

Answer 2

En pocas palabras, Wrapper (el objeto) no es una función, es sólo un objeto con un método de aplicación. Esto no tiene absolutamente nada que ver con que el objeto sea también un extractor.

Prueba esto:

class Wrapper(val x: Int) { 
    override def toString = "Wrapper(" + x + ")" 
    // other methods elided 
} 

object Wrapper extends (Int => Wrapper) { 
    def apply(x: Int) = new Wrapper(x) 
    def unapply(w: Wrapper): Option[Int] = Some(w.x) 
} 

def higherOrder(f: Int => Wrapper) = println(f(42)) 

También hice el parámetro a Wrapper un val cambiado de sitio y el parámetro y el valor de retorno en su definición de unapply para que se correspondería con el comportamiento de casos y clase.