Est-ce un manque de temps, un problème technique ou une raison pour laquelle il ne devrait pas exister ?
Réponses
Trop de publicités?C'est juste une affaire manquante qui sera probablement remplie un jour. Il n'y a aucune raison de ne pas le faire, et dans certains cas, il serait considérablement plus rapide que l'arbre immuable (puisque les modifications nécessitent log(n) créations d'objets avec un arbre immuable et seulement 1 avec un arbre mutable).
Je suppose que la raison est que le fait d'avoir une variante mutable n'apporte pas un grand avantage. Il y a certains cas mentionnés dans les autres réponses où une carte mutable pourrait être un peu plus efficace, par exemple lors du remplacement d'une valeur déjà existante : Une variante mutable permettrait d'éviter la création de nouveaux nœuds, mais la complexité resterait la même. O(log n) .
Si vous voulez garder une référence partagée à la carte, vous pouvez utiliser ImmutableMapAdaptor
qui transforme toute carte immuable en une structure mutable.
Vous remarquerez également que TreeSet
n'a pas non plus d'équivalent mutable. C'est parce qu'ils partagent la classe de base commune RedBlack
et la structure de données sous-jacente qui conserve les Trees
ordonné par éléments ou clés est un arbre rouge-noir . Je ne connais pas trop cette structure de données, mais elle est assez complexe (l'insertion et la suppression sont assez coûteuses par rapport aux autres cartes), donc je suppose que cela avait quelque chose à voir avec le fait qu'une variante mutable n'était pas incluse.
Fondamentalement, c'est probablement parce que la structure de données sous-jacente n'est pas facilement mutable, alors TreeMap
ne l'est pas. Donc, pour répondre à votre question, c'est un problème technique. C'est tout à fait possible, mais il n'y a pas beaucoup de cas d'utilisation pour cela.
Il peut y avoir des raisons de performance pour un mutable TreeMap
mais en général, vous pouvez utiliser une carte immuable de la même manière qu'une carte mutable. Il suffit de l'affecter à un var
plutôt qu'un val
. Ce serait la même chose que pour HashMap
qui a des variantes mutables et immuables :
val mh = collection.mutable.HashMap[Int, Int]()
var ih = collection.immutable.HashMap[Int, Int]()
mh += (1 -> 2)
ih += (1 -> 2)
mh // scala.collection.mutable.HashMap[Int,Int] = Map(1 -> 2)
ih // scala.collection.immutable.HashMap[Int,Int] = Map(1 -> 2)