38

是没有时间,一些技术问题,还是有它不应该存在的原因?

4

5 回答 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 回答