val-mutable versus var-inmutable en Scala

¿Existe alguna guía en Scala sobre cuándo usar val con una colección mutable versus usar var con una colección inmutable? ¿O realmente deberías apuntar a val con una colección inmutable?

El hecho de que existan ambos tipos de colección me da muchas opciones y, a menudo, no sé cómo tomar esa decisión.

Esta es una pregunta bastante común. Lo difícil es encontrar los duplicados.

Debes luchar por la transparencia referencial . Lo que eso significa es que, si tengo una expresión "e", podría hacer una val x = ey reemplazarla epor x. Esta es la propiedad que rompe la mutabilidad. Siempre que necesite tomar una decisión de diseño, maximice la transparencia referencial.

En la práctica, un método local vares el más seguro varque existe, ya que no escapa al método. Si el método es corto, mejor aún. Si no es así, intente reducirlo extrayendo otros métodos.

Por otro lado, una colección mutable tiene el potencial de escapar, incluso si no es así. Al cambiar el código, es posible que desee pasarlo a otros métodos o devolverlo. Ese es el tipo de cosas que rompe la transparencia referencial.

En un objeto (un campo) sucede más o menos lo mismo, pero con consecuencias más nefastas. De cualquier forma el objeto tendrá estado y, por tanto, romperá la transparencia referencial. Pero tener una colección mutable significa que incluso el objeto en sí mismo podría perder el control de quién lo está cambiando.

Si trabaja con colecciones inmutables y necesita "modificarlas", por ejemplo, agregarles elementos en un bucle, entonces debe usar vars porque necesita almacenar la colección resultante en algún lugar. Si solo lee de colecciones inmutables, use vals.

En general, asegúrese de no confundir referencias y objetos. vals son referencias inmutables (punteros constantes en C). Es decir, cuando lo use val x = new MutableFoo(), podrá cambiar el objeto al que xapunta, pero no podrá cambiar a qué objeto x apunta. Lo contrario es válido si usa var x = new ImmutableFoo(). Siguiendo mi consejo inicial: si no necesita cambiar a qué objeto apunta un punto de referencia, use vals.

La mejor forma de responder a esto es con un ejemplo. Supongamos que tenemos algún proceso que simplemente recopila números por alguna razón. Deseamos registrar estos números y enviaremos la colección a otro proceso para hacer esto.

Por supuesto, todavía estamos recopilando números después de enviar la colección al registrador. Y digamos que hay una sobrecarga en el proceso de registro que retrasa el registro real. Ojalá puedas ver a dónde va esto.

Si almacenamos esta colección en un mutable val, (mutable porque estamos agregando continuamente), esto significa que el proceso que realiza el registro buscará el mismo objeto que aún está siendo actualizado por nuestro proceso de recolección. Esa colección puede actualizarse en cualquier momento, por lo que cuando llegue el momento de iniciar sesión, es posible que no estemos registrando la colección que enviamos.

Si usamos un inmutable var, enviamos una estructura de datos inmutable al registrador. Cuando agreguemos más números a nuestra colección, reemplazaremos nuestro varcon una nueva estructura de datos inmutable . ¡Esto no significa que la colección enviada al registrador sea reemplazada! Todavía hace referencia a la colección que se envió. Entonces nuestro registrador registrará la colección que recibió.

Creo que los ejemplos de esta publicación de blog arrojarán más luz, ya que la cuestión de qué combo usar se vuelve aún más importante en escenarios de concurrencia: la importancia de la inmutabilidad para la concurrencia . Y ya que estamos en eso, tenga en cuenta el uso preferido de sincronizado frente a @ volátil frente a algo como AtomicReference: tres herramientas

var immutable vs. val mutable

Además de muchas excelentes respuestas a esta pregunta. A continuación, se muestra un ejemplo sencillo que ilustra los peligros potenciales de val mutable:

Los objetos mutables se pueden modificar dentro de los métodos, que los toman como parámetros, mientras que no se permite la reasignación.

import scala.collection.mutable.ArrayBuffer

object MyObject {
    def main(args: Array[String]) {

        val a = ArrayBuffer(1,2,3,4)
        silly(a)
        println(a) // a has been modified here
    }

    def silly(a: ArrayBuffer[Int]): Unit = {
        a += 10
        println(s"length: ${a.length}")
    }
}

Resultado:

length: 5
ArrayBuffer(1, 2, 3, 4, 10)

Algo como esto no puede suceder con var immutable, porque no se permite la reasignación:

object MyObject {
    def main(args: Array[String]) {
        var v = Vector(1,2,3,4)
        silly(v)
        println(v)
    }

    def silly(v: Vector[Int]): Unit = {
        v = v :+ 10 // This line is not valid
        println(s"length of v: ${v.length}")
    }
}

Resultados en:

error: reassignment to val

Dado que los parámetros de función se tratan como valesta reasignación no está permitida.