Parece que scala.math.PartialOrdering.lteq siempre debe ser definido como (o al menos, dan el mismo resultado que):¿Por qué Scala.math.PartialOrdering.lteq es abstracto, en lugar de definido en términos de .tryCompare?
override def lteq(x: Pattern, y: Pattern) = {
tryCompare(x, y).map(_ <= 0).getOrElse(false)
}
¿Hay alguna razón esta implementación no se da en el rasgo scala.math.PartialOrdering?
Mi suposición es alentar a escribir un lteq más eficiente, ya que todos los demás métodos se remontan a lteq. Entonces, no querrá crear un Option, y luego asignarlo. Yo prefiero pedir a la opuesta - por qué no es tryCompare implementado por defecto, por ejemplo .:
def tryCompare(x: T, y: T) = {
val p1 = lteq(x, y)
val p2 = lteq(y, x)
if (p1) {
if(p2) Some(0) else Some(-1)
} else if (p2) Some(1) else None
}
... y no tendría que escribir la fea override modificador en la aplicación de lteq.
Por lo que yo puedo ver tryCompare no se usa nunca jamás en toda la Scala cuerpo biblioteca estándar, por lo que tal vez es sólo un 'por delante del izquierdo' ...
De un matemático de (que soy yo!) Punto de vista , de alguna manera se siente mejor dejar sin implementar 'tryCompare', pero estoy de acuerdo en que si estás animando a la gente a escribir un código optimizado, entonces' lteq' es un mejor candidato para anular. –