2010-07-13 11 views

Respuesta

14
val f: Function2[Simple, String, Int] = _.doit(_) 
+1

Llamado "aplicación parcial". Como se muestra aquí, es un caso especial. Como su nombre indica, algunos argumentos pueden ser suministrados en la aplicación parcial y la función resultante tiene una aritmética N-M donde N era la aridad del método original (o función) y M es el número de argumentos fijados en la aplicación parcial. –

+0

Perfecto. Me preguntaba cómo el compilador descubriría si el método doit realmente existe; Veo que la tipificación explícita funciona aquí. ¡Gracias! –

12

mismo que sepp2k, simplemente usando una sintaxis diferente

val f = (s:Simple, str:String) => s.doit(str) 
9

Para aquellos de vosotros que no gozan de tipos escribiendo:

scala> val f = (_: Simple).doit _ 
f: (Simple) => (String) => Int = <function1> 

Siguiendo un método por el _ obras de cualquier arity:

scala> trait Complex {       
    | def doit(a: String, b: Int): Boolean 
    | }          
defined trait Complex 

scala> val f = (_: Complex).doit _    
f: (Complex) => (String, Int) => Boolean = <function1> 

Esto está cubierto por una combinación de §6.23 "Sintaxis de marcador de posición para funciones anónimas" y §7.1 "Valores de método" de Scala Reference

+0

¿Cuáles son las implicaciones prácticas de tener una función del tipo (Simple) => (String) => Int vs. del tipo (Simple, String) => Int? Sé que el primero se llama con f (obj) ("str") y el último con f (obj, "str"), y el primero devuelve otro objeto de función si simplemente lo llama con una lista de parámetros: f (obj). Pero, ¿qué sucede detrás de escena en términos de cantidad de objetos creados y número de invocaciones de métodos? –

+0

Se crean dos objetos Function1 en lugar de un objeto Function2, con un nivel extra de direccionamiento indirecto. – retronym

Cuestiones relacionadas