是没有时间，一些技术问题，还是有它不应该存在的原因？
问问题
9170 次
5 回答
27
这只是一个缺失的情况，可能最终会被填补。没有理由不这样做，在某些情况下，它会比不可变树快得多（因为修改需要使用不可变树创建 log(n) 对象，并且只有 1 个带有可变树）。
编辑：实际上它是在 2.12 中填写的。
可变树图。
（也有对应的Set。）
于 2010-12-26T06:49:45.610 回答
6
Meanwhile you can use the Java TreeMap, which is exactly what you need.
val m = new java.util.TreeMap[String, Int]()
m.put("aa", 2)
m.put("cc", 3)
于 2012-02-23T07:55:29.313 回答
6
我认为原因是拥有可变变体并没有带来很大的好处。在其他答案中提到了一些情况，当可变映射可能更有效时，例如在替换已经存在的值时：可变变体将节省新节点的创建，但复杂度仍为O(log n) .
如果要保留对映射的共享引用，可以使用ImmutableMapAdaptorwhich 将任何不可变映射包装到可变结构中。
于 2012-10-23T16:38:15.840 回答
2
您还会注意到它TreeSet也没有可变的等价物。这是因为它们共享共同的基类RedBlack，而保持Trees元素或键排序的底层数据结构是一棵红黑树。我不太了解这种数据结构，但它非常复杂（与其他 Map 相比，插入和删除非常昂贵），所以我认为这与不包含可变变体有关。
基本上，这可能是因为底层数据结构不容易可变所以TreeMap不是。所以，要回答你的问题，这是一个技术问题。虽然它绝对可以完成，但它的用例并不多。
于 2010-12-26T01:03:23.217 回答
1
mutable 可能存在性能原因TreeMap，但通常您可以像使用可变映射一样使用不可变映射。您只需将其分配给 avar而不是 a val。它与 for 相同HashMap，具有可变和不可变的变体：
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)
于 2012-02-15T03:24:41.253 回答