scala - lenguaje - ¿Cómo puedo hacer ''if..else'' dentro de una comprensión?

lenguaje c if else ejemplos

Question

Estoy haciendo una pregunta muy básica que me confundió recientemente. Quiero escribir una expresión de Scala For para hacer algo como lo siguiente:

for (i <- expr1) {
  if (i.method) {
    for (j <- i) {
      if (j.method) {
        doSomething()
      } else {
        doSomethingElseA()
      }
    }
  } else {
    doSomethingElseB()
  }
}

El problema es que, en los múltiples generadores para expresión, no sé dónde puedo poner cada uno para expresión cuerpo.

for {i <- expr1
  if(i.method) // where can I write the else logic ?
  j <- i 
  if (j.method)
} doSomething()

¿Cómo puedo reescribir el código en Scala Style?

Answer 1

El primer código que escribiste es perfectamente válido, por lo que no es necesario volver a escribirlo. En otro lugar dijiste que querías saber cómo hacerlo al estilo Scala. Realmente no hay un "estilo Scala", pero asumiré un estilo más funcional y lo abordaré.

for (i <- expr1) {
  if (i.method) {
    for (j <- i) {
      if (j.method) {
        doSomething()
      } else {
        doSomethingElseA()
      }
    }
  } else {
    doSomethingElseB()
  }
}

La primera preocupación es que esto no devuelve ningún valor. Todo lo que hace son los efectos secundarios, que también deben evitarse. Entonces el primer cambio sería así:

val result = for (i <- expr1) yield {
  if (i.method) {
    for (j <- i) yield {
      if (j.method) {
        returnSomething()
        // etc

Ahora, hay una gran diferencia entre

for (i <- expr1; j <- i) yield ...

y

for (i <- expr1) yield for (j <- i) yield ...

Devuelven cosas diferentes, y hay momentos en que quieres lo último, no lo primero. Aunque asumiré que quieres lo primero. Ahora, antes de continuar, vamos a arreglar el código. Es feo, difícil de seguir y poco informativo. Vamos a refactorizarlo extrayendo métodos.

def resultOrB(j) = if (j.method) returnSomething else returnSomethingElseB
def nonCResults(i) = for (j <- i) yield resultOrB(j)
def resultOrC(i) = if (i.method) nonCResults(i) else returnSomethingC
val result = for (i <- expr1) yield resultOrC(i)

Ya está mucho más limpio, pero no está devolviendo lo que esperamos. Veamos la diferencia:

trait Element
object Unrecognized extends Element
case class Letter(c: Char) extends Element
case class Punct(c: Char) extends Element
val expr1 = "This is a silly example." split "//b"

def wordOrPunct(j: Char) = if (j.isLetter) Letter(j.toLower) else Punct(j)
def validElements(i: String) = for (j <- i) yield wordOrPunct(j)
def classifyElements(i: String) = if (i.nonEmpty) validElements(i) else Unrecognized
val result = for (i <- expr1) yield classifyElements(i)

El tipo de result es Array[AnyRef] , mientras que el uso de múltiples generadores generaría un Array[Element] . La parte fácil de la solución es esta:

val result = for {
  i <- expr1
  element <- classifyElements(i)
} yield element

Pero eso solo no funcionará, porque AnyRef devuelve AnyRef , y queremos que devuelva una colección. Ahora, validElements devuelve una colección, por lo que no es un problema. Solo necesitamos arreglar la else parte. Como validElements está devolviendo un IndexedSeq , también lo devolveremos en la parte else . El resultado final es:

trait Element
object Unrecognized extends Element
case class Letter(c: Char) extends Element
case class Punct(c: Char) extends Element
val expr1 = "This is a silly example." split "//b"

def wordOrPunct(j: Char) = if (j.isLetter) Letter(j.toLower) else Punct(j)
def validElements(i: String) = for (j <- i) yield wordOrPunct(j)
def classifyElements(i: String) = if (i.nonEmpty) validElements(i) else IndexedSeq(Unrecognized)
val result = for {
  i <- expr1
  element <- classifyElements(i)
} yield element

Eso hace exactamente la misma combinación de bucles y condiciones que presentaste, pero es mucho más legible y fácil de cambiar.

Sobre el rendimiento

Creo que es importante tener en cuenta una cosa sobre el problema presentado. Vamos a simplificarlo:

for (i <- expr1) {
  for (j <- i) {
    doSomething
  }
}

Ahora, eso se implementa con foreach (consulte here , u otras preguntas y respuestas similares). Eso significa que el código anterior hace exactamente lo mismo que este código:

for {
  i <- expr1
  j <- i
} doSomething

Exactamente lo mismo. Eso no es cierto en absoluto cuando uno está utilizando el yield . Las siguientes expresiones no producen el mismo resultado:

for (i <- expr1) yield for (j <- i) yield j

for (i <- expr1; j <- i) yield j

El primer fragmento de código se implementará a través de dos llamadas de map , mientras que el segundo fragmento de flatMap utilizará un map flatMap y un map .

Por lo tanto, es solo en el contexto del yield que incluso tiene algún sentido preocuparse por el anidamiento for bucles o el uso de múltiples generadores. Y, de hecho, los generadores representan el hecho de que algo se está generando , lo cual es cierto solo para las verdaderas comprensiones (las que yield algo).

Answer 2

La parte

for (j <- i) {
   if (j.method) {
     doSomething(j)
   } else {
     doSomethingElse(j)
   }
 }

se puede reescribir como

for(j <- i; e = Either.cond(j.method, j, j)) {
  e.fold(doSomething _, doSomethingElse _)  
}  

(por supuesto, puedes usar un rendimiento si tus métodos do ... devuelven algo)

Aquí no es tan útil, pero si tiene una estructura anidada más profunda, podría ...

Answer 3

Las condiciones especificadas en un Scala para la operación actúan para filtrar los elementos de los generadores. Los elementos que no satisfacen las condiciones se descartan y no se presentan al bloque de código / rendimiento.

Lo que esto significa es que si desea realizar operaciones alternativas basadas en una expresión condicional, la prueba debe aplazarse hasta el bloque de rendimiento / código.

También tenga en cuenta que la operación para la operación es relativamente costosa (actualmente), por lo que quizás sea más apropiado un enfoque iterativo más simple, tal vez algo como:

expr1 foreach {i =>
  if (i.method) {
    i foreach {j =>
      if (j.method)
        doSomething()
      else
        doSomethingElseA()
    }
  }
  else
    doSomethingElseB()
}

Actualizar:

Si debe usar una para la comprensión y puede vivir con algunas restricciones, esto podría funcionar:

for (i <- expr1; j <- i) {
  if (i.method) {if (j.method) doSomething() else doSomethingElseA()} else doSomethingElseB()
}

Answer 4

No se puede. La construcción for (expr; if) simplemente filtra el elemento que debe manejarse en el bucle.

Answer 5

Si el orden no es importante para las llamadas a doSomething () y doSomethingElse (), puede reorganizar el código de esta manera.

val (tmp, no1) = expr1.partition(_.method)
val (yes, no2) = tmp.partition(_.method)

yes.foreach(doSomething())
no1.foreach(doSomethingElse())
no2.foreach(doSomethingElse())

Para responder a su pregunta original, creo que, para comprender, puede ser bastante bueno para casos de uso específicos, y su ejemplo no encaja bien.

Answer 6

import scalaz._; import Scalaz._

val lhs = (_ : List[X]) collect { case j if j.methodJ => doSomething(j) } 
val rhs = (_ : List[X]) map doSomethingElse
lhs <-: (expr1 partition methodI) :-> rhs