¿Cuál es la diferencia entre una definición var y val en Scala?

Como muchos otros han dicho, el objeto asignado a un val no puede ser reemplazado, y el objeto asignado a un var puede. Sin embargo, dicho objeto puede tener su estado interno modificado. Por ejemplo:

class A(n: Int) {
  var value = n
}

class B(n: Int) {
  val value = new A(n)
}

object Test {
  def main(args: Array[String]) {
    val x = new B(5)
    x = new B(6) // Doesn't work, because I can't replace the object created on the line above with this new one.
    x.value = new A(6) // Doesn't work, because I can't replace the object assigned to B.value for a new one.
    x.value.value = 6 // Works, because A.value can receive a new object.
  }
}

Así que, aunque no podamos cambiar el objeto asignado a x, podríamos cambiar el estado de ese objeto. En la raíz de ella, sin embargo, había un var.

Ahora bien, la inmutabilidad es algo bueno por muchas razones. Primero, si un objeto no cambia el estado interno, no tienes que preocuparte si alguna otra parte de tu código lo está cambiando. Por ejemplo:

x = new B(0)
f(x)
if (x.value.value == 0)
  println("f didn't do anything to x")
else
  println("f did something to x")

Esto se vuelve particularmente importante con sistemas multihilo. En un sistema multiproceso, puede ocurrir lo siguiente:

x = new B(1)
f(x)
if (x.value.value == 1) {
  print(x.value.value) // Can be different than 1!
}

Si usa val exclusivamente, y solo use estructuras de datos inmutables (es decir, evite arrays, todo en scala.collection.mutable, etc.), puede estar seguro de que esto no sucederá. Es decir, a menos que haya algún código, tal vez incluso un marco, haciendo trucos de reflexión can la reflexión puede cambiar los valores "inmutables", por desgracia.

Esa es una razón, pero hay otra razón para ello. Cuando usas var, puedes ser tentado a reutilizar el mismo var para múltiples propósitos. Esto tiene algunos problemas:

• Será más difícil para las personas que leen el código saber cuál es el valor de una variable en una cierta parte del código.
• Puede olvidarse de volver a inicializar la variable en alguna ruta de código, y terminar pasando valores incorrectos codificar.

En pocas palabras, usar val es más seguro y conduce a un código más legible.

Podemos, entonces, ir en la otra dirección. Si val es eso mejor, ¿por qué tener var en absoluto? Bueno, algunos idiomas tomaron esa ruta, pero hay situaciones en las que la mutabilidad mejora el rendimiento, mucho.

Por ejemplo, tomemos un Queue inmutable. Cuando ya sea enqueue o dequeue cosas en él, se obtiene un nuevo objeto Queue. ¿Cómo entonces, irías sobre el procesamiento de todos los elementos en ¿eso?

Voy a ir a través de eso con un ejemplo. Digamos que tienes una cola de dígitos, y quieres componer un número de ellos. Por ejemplo, si tengo una cola con 2, 1, 3, en ese orden, quiero recuperar el número 213. Primero vamos a resolverlo con un mutable.Queue:

def toNum(q: scala.collection.mutable.Queue[Int]) = {
  var num = 0
  while (!q.isEmpty) {
    num *= 10
    num += q.dequeue
  }
  num
}

Este código es rápido y fácil de entender. Su principal inconveniente es que la cola que se pasa es modificada por toNum, por lo que debe hacer una copia de ella de antemano. Ese es el tipo de gestión de objetos que la inmutabilidad te libera de.

Ahora, vamos a convertirlo en un immutable.Queue:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  def recurse(qr: scala.collection.immutable.Queue[Int], num: Int): Int = {
    if (qr.isEmpty)
      num
    else {
      val (digit, newQ) = qr.dequeue
      recurse(newQ, num * 10 + digit)
    }
  }
  recurse(q, 0)
}

Debido a que no puedo reutilizar alguna variable para realizar un seguimiento de mi num, como en el ejemplo anterior, necesito recurrir a la recursión. En este caso, es una recursión de cola, que tiene un rendimiento bastante bueno. Pero ese no es siempre el caso: a veces simplemente no hay una solución de recursión de cola buena (legible, simple).

Tenga en cuenta, sin embargo, que puedo reescribir ese código para usar un immutable.Queue y un var en el mismo tiempo! Por ejemplo:

def toNum(q: scala.collection.immutable.Queue[Int]) = {
  var qr = q
  var num = 0
  while (!qr.isEmpty) {
    val (digit, newQ) = qr.dequeue
    num *= 10
    num += digit
    qr = newQ
  }
  num
}

Este código sigue siendo eficiente, no requiere recursividad, y no necesita preocuparse si tiene que hacer una copia de su cola o no antes de llamar a toNum. Naturalmente, evité reutilizar variables para otros propósitos, y ningún código fuera de esta función las ve, así que no necesito preocuparme por sus valores cambiando de una línea a la siguiente except excepto cuando lo hago explícitamente.

Scala optó por dejar que el programador haga eso, si el programador consideró que era la mejor solución. Otros idiomas han optado por dificultar dicho código. El precio que paga Scala (y cualquier lenguaje con mutabilidad generalizada) es que el compilador no tiene tanto margen para optimizar el código como podría hacerlo de otra manera. La respuesta de Java a eso es optimizar el código basado en el perfil de tiempo de ejecución. Podríamos seguir y seguir sobre los pros y los contras de cada lado.

Personalmente, creo que Scala encuentra el equilibrio correcto, por ahora. No es perfecto, de lejos. Creo que tantoClojure comoHaskell tienen nociones muy interesantes no adoptadas por Scala, pero Scala también tiene sus propias fortalezas. Veremos lo que viene en el futuro.