Quelle est la différence entre une définition var et val dans Scala?

, Comme tant d'autres l'ont dit, l'objet affecté à un val ne peut pas être remplacé, et l'objet affecté à un var peut. Cependant, ledit objet peut avoir son état interne modifié. Par exemple:

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.
  }
}

Donc, même si nous ne pouvons pas changer l'objet assigné à x, nous pourrions changer l'état d'un objet. À la racine de celui-ci, cependant, il y avait un var.

Maintenant, l'immuabilité est une bonne chose pour de nombreuses raisons. Tout d'abord, si un objet ne change pas d'état interne, vous n'avez pas vous devez vous inquiéter si une autre partie de votre code le change. Par exemple:

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")

Cela devient particulièrement important avec les systèmes multithread. Dans un système multithread, ce qui suit peut se produire:

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

Si vous utilisez val exclusivement, et n'utilisez que des structures de données immuables (c'est-à-dire, évitez les tableaux, tout dans scala.collection.mutable, etc.), vous pouvez être assuré que cela n'arrivera pas. Autrement dit, à moins qu'il n'y ait du code, peut-être même un framework, faire des astuces de réflexion - la réflexion peut changer les valeurs "immuables", malheureusement.

C'est une raison, mais il y en a une autre. Lorsque vous utilisez var, vous pouvez être tenté en réutilisant le même var fins multiples. Cela a quelques problèmes:

• Il sera plus difficile pour les personnes lisant le code de savoir quelle est la valeur d'une variable dans une certaine partie du code.
• Vous pouvez oublier de réinitialiser la variable dans un chemin de code, et finir par passer de mauvaises valeurs en aval dans le code.

En termes simples, l'utilisation de val est plus sûre et conduit à un code plus lisible.

On peut alors aller dans l'autre sens. Si val est-ce mieux, pourquoi avoir var du tout? Eh bien, certaines langues ont pris cette voie, mais il y a des situations dans lesquelles la mutabilité améliore les performances, beaucoup.

Par exemple, prenez un Queue immuable. Lorsque vous enqueue ou dequeue choses, vous obtiendrez une nouvelle Queue objet. Comment alors, iriez-vous traiter tous les éléments dans il?

Je vais passer en revue cela avec un exemple. Disons que vous avez une file d'attente de chiffres, et que vous voulez en composer un nombre. Par exemple, si j'ai une file d'attente avec 2, 1, 3, dans cet ordre, je veux revenir le numéro 213. Résolvons-le d'abord avec un mutable.Queue:

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

Ce code est rapide et facile à comprendre. Son principal inconvénient est que la file d'attente qui est passée est modifiée par toNum, Vous devez donc en faire une copie au préalable. C'est le genre de gestion d'objets qui immutabilité vous rend libre de.

Maintenant, cachons-le à 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)
}

Parce que je ne peux pas réutiliser une variable pour garder une trace de mon num, comme dans l'exemple précédent, je dois recourir à la récursivité. Dans ce cas, il s'agit d'une récursion de queue, qui a de très bonnes performances. Mais ce n'est pas toujours le cas: parfois, il n'y a tout simplement pas de bonne solution de récursion de queue (lisible, simple).

Notez, cependant, que je peux réécrire ce code pour utiliser un immutable.Queue et a var, au même temps! Par exemple:

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
}

Ce code est toujours efficace, ne nécessite pas de récursivité, et vous n'avez pas besoin de vous inquiéter si vous devez faire une copie de votre file d'attente ou non avant d'appeler toNum. Naturellement, j'ai évité de réutiliser des variables à d'autres fins, et aucun code en dehors de cette fonction ne les voit, donc je n'ai pas besoin de m'inquiéter de voir leurs valeurs changer d'une ligne à l'autre-sauf quand je le fais explicitement.

Scala a choisi de laisser le programmeur le faire, si le programmeur considéré comme la meilleure solution. D'autres langues ont choisi de rendre ce code difficile. Le prix payé par Scala (et tout langage avec une mutabilité généralisée) est que le compilateur n'a pas autant de marge de manœuvre dans l'optimisation du code qu'il pourrait autrement. La réponse de Java à cela est d'optimiser le code en fonction du profil d'exécution. Nous pourrions continuer et sur les avantages et les inconvénients de chaque côté.

Personnellement, je pense que Scala trouve le bon équilibre, pour l'instant. Il n'est pas parfait, et de loin. Je pense que Clojure et Haskell ont des notions très intéressantes qui ne sont pas adoptées par Scala, mais Scala a aussi ses propres forces. Nous allons voir ce qui arrive sur l'avenir.