3

前几天我想知道为什么 scala.collection.Map 将其 unzip 方法定义为

def unzip [A1, A2] (implicit asPair: ((A, B)) ⇒ (A1, A2)): (Iterable[A1], Iterable[A2])

由于该方法“仅”返回一对 Iterable 而不是一对 Seq，因此不能保证原始映射中的键/值对出现在返回序列中的匹配索引处，因为 Iterable 不保证遍​​历的顺序。所以如果我有一个

Map((1,A), (2,B))

，然后在调用之后

Map((1,A), (2,B)) unzip

我可能最终得到

... = (List(1, 2),List(A, B))

和

... = (List(2, 1),List(B, A))

虽然我可以想象这背后与存储相关的原因（例如，想想 HashMaps），但我想知道你们对这种行为的看法。Map.unzip 方法的用户可能会认为这些项目是以相同的配对顺序返回的（我敢打赌，这可能几乎总是如此），但因为不能保证这反过来会产生难以发现的错误图书馆用户的代码。

也许应该在随附的 scaladoc 中更明确地表达这种行为？

编辑：请注意，我并不是将地图称为有序集合。我只对解压缩后的“匹配”序列感兴趣，即

val (keys, values) = someMap.unzip

它适用于所有 i (keys(i), values(i)) 是原始映射的一个元素。

4

4 回答 4

3

如果你展开unzip's description，你会得到答案：

definition classes: GenericTraversableTemplate

换句话说，它没有专门用于Map.

不过，你的论点是合理的，我敢说，如果你用你的推理开一张增强票，你可能会得到你的愿望。特别是如果你继续制作一个补丁——如果没有别的，至少你会在这样做的过程中学到更多关于 Scala 集合的知识。

于 2011-03-31T15:15:21.620 回答
3

实际上，您提供的示例不会发生。将Map始终以成对的方式解压缩。您不保证订购的陈述Iterable并不完全正确。更准确地说，任何给定Iterable的都不必保证顺序，但这取决于实现。在 的情况下Map.unzip，无法保证对的顺序，但是对中的项目不会改变它们匹配的方式——匹配是Map. 您可以阅读源代码以GenericTraversableTemplate验证情况是否如此。

于 2011-03-31T15:41:26.673 回答
2

通常，地图没有自然序列：它们是无序的集合。您的密钥恰好具有自然顺序这一事实不会改变一般情况。

（但是我无法解释为什么 Map 有一个zipWithIndex方法。这为我的观点提供了一个反驳。我想它是为了与其他集合保持一致，尽管它提供了索引，但不能保证它们是后续调用相同。）

于 2011-03-31T14:53:41.107 回答
0

如果您使用 LinkedHashMap 或 LinkedHashSet，则迭代器应该以原始插入顺序返回对。其他 HashMap，是的，你无法控制。保留原始插入顺序在 UI 上下文中非常有用，例如，它允许您在 Web 应用程序中的任何列上重新排列表格，而无需更改类型。

于 2011-03-31T20:29:30.307 回答