2011-10-11 11 views

Respuesta

10
  1. Debido a que es trivial para lograr el mismo levantando la función parcial

    partialFunc.lift(arg) getOrElse (totalFunc(arg))

  2. Debido Scala, en general, trata de evitar la sobrecarga

  3. Porque nadie pensó que añadir que, y probablemente no se haya necesitado hasta ahora

  4. Porque cada uno d todos los métodos añadido a la biblioteca estándar incurre en un costo cada vez mayor en términos de afecto aguas abajo

+2

+1. Gracias por la respuesta. Respondiendo a tus balas ... 1) Eso no es muy compositivo, y me hace mencionar y repetir 'arg'. Además, si usamos la trivialidad de la implementación como argumento, entonces Scala stdlib tendría que reducirse a casi la mitad de su tamaño actual. :-) 2) Punto justo. 3) Lo necesité un par de veces en los últimos tres días. 4) Este es un método trivial para agregar (como lo demostró). No creo que agregue ningún gasto de mantenimiento notable. – missingfaktor

+0

@missingfaktor ¿No puedes hacer '(pf.lift <*> f) {_ getOrElse _} apply arg' o algo similar? –

+1

@oxbow_lakes: Sí, podría hacerlo de esa manera, pero sigue siendo demasiado detallado (y críptico) para mi gusto. – missingfaktor

1

Considérese,

scala> object O { 
    | def f(g: Int => Int) = g(1) 
    | def f(g: PartialFunction[Int, Int]) = g(2).toString 
    | } 
defined module O 

scala> O f { _ * 1 } 
res3: Int = 1 

Así pues, cómo se encadenan funciones parciales ahora? O, en otras palabras, si la sobrecarga que describa estaba en la biblioteca, y me escribió esto:

type PF = PartialFunction[Any, Int] 
val pf1: PF = { case n: Int => n } 
val pf2: PF = pf1 orElse { case x: String => x.length } 
val pf3: PF = pf2 orElse { case d: Double => d.toInt } 

me gustaría obtener un mensaje de error en pf2 debido a la ambigüedad del tipo. Si, en cambio, escribo:

val pf2 = pf1 orElse ((_: Any) match { case x: String => x.length }) 
val pf3 = pf2 orElse ((_: Any) match { case d: Double => d.toInt }) 

Entonces me sale un error en pf3, porque pf2 habrá un Function1.

+0

No entiendo la pregunta. :(¿Puedes por favor elaborar? – missingfaktor

+0

Ahora entiendo tu punto. No me importa mucho el nombre. Podrían haberlo agregado bajo otro nombre. – missingfaktor

+0

@missingfaktor Ah, de acuerdo. Sugiero 'de lo contrario'. :-) –

0

Parece que no hay una buena razón para la ausencia de estas funciones en la biblioteca estándar, aparte de la supervisión o tal vez nadie las necesita tan a menudo como para tenerlas en la biblioteca estándar.

He definido una conversión implícita de A => B a PartialFunction[A, B] que parece ocuparse de este y otros casos similares, y no da lugar a efectos adversos.

scala> implicit def fToPf[A, B](f: A => B) = new PartialFunction[A, B] { 
    | def isDefinedAt(a: A) = true 
    | def apply(a: A) = f(a) 
    | } 
fToPf: [A, B](f: A => B)java.lang.Object with PartialFunction[A,B] 
Cuestiones relacionadas