Scala 的 Map.unzip 返回的原因 (Iterable, Iterable)答案

【问题标题】：Reason for Scala's Map.unzip returning (Iterable, Iterable)Scala 的 Map.unzip 返回的原因 (Iterable, Iterable)
【发布时间】：2011-07-26 23:35:48
【问题描述】：

前几天我想知道为什么 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 中更明确地表达这种行为？

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

val (keys, values) = someMap.unzip

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

【问题讨论】：

标签： scala dictionary unspecified-behavior

【解决方案1】：

地图通常没有自然顺序：它们是无序的集合。您的键碰巧具有自然顺序这一事实不会改变一般情况。

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

【讨论】：

最好将zipWithIndex 视为一个方便的帮手。它并没有特别说明Map 的顺序，它只是提供了一种方便的机制，这种机制经常被不提供类似调用的语言重写。
感谢您的回答。但是，OP 没有将地图假定为 ordered 集合。

【解决方案2】：

如果你展开unzip的描述，你会得到答案：

definition classes: GenericTraversableTemplate

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

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

【讨论】：

【解决方案3】：

其实你给出的例子不会出现。 Map 将始终以成对的方式解压缩。您关于Iterable 不保证订购的说法并不完全正确。更准确地说，任何给定的Iterable 不必保证顺序，但这取决于实现。在Map.unzip 的情况下，无法保证对的顺序，但对中的项目不会改变它们匹配的方式——匹配是Map 的基本属性。您可以阅读the source 到GenericTraversableTemplate 来验证是否是这种情况。

【讨论】：

【解决方案4】：

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

【讨论】：

感谢您的回答。然而，我试图维护的不是插入顺序。请参阅上面对 OP 的编辑。