更好的词典名称

Question

我正在设计一种编程语言，所以我一直在考虑基类型的命名方式。

“词典”似乎是词典的坏名称。它们不是有组织的单词列表及其定义;他们不处理单词，他们没有定义，也不是列表。他们与“词典”这个词的唯一模糊联系是，人们执行“查找”就像使用纸质词典一样（这就像把它称为“电话簿”一样好。）

“HashTable”描述了可能发生变化的实现。

“关联数组”（来自JavaScript）得到分数，因为“关联”对于它的作用是一个很好的形容词，但是因为“数组”也描述了一个实现，所以会失去分数，更糟糕的是，它描述的不准确。

“键/值对集”似乎最准确，但它太长而无用（你真的想每次输入“KeyValuePairSet”吗？）。

如果我们将“键/值对”称为“关联”，我们将获得“AssociationSet”。这对我来说是最好的，但不会跳出来作为正确的答案;它仍然很长，“设置”仍然感觉有点不对劲。 “AssociationList”更糟糕（“list”意味着排序，而不是那里）。我简单地只考虑了“关联”，但这听起来更像是我要命名的实例而不是类。 “RelationSet”和“PairSet”更短但描述性更低（两者都没有捕获到它是一种单向关系键值的事实;键的值在字典上下文中没有意义）。

任何想法可能是什么更好的词典名称？

Answer 1

“地图”？

您正在将一个值映射到另一个值。

Answer 2

词典是标准的计算机科学术语。抱怨真实世界字典与抽象数据类型不同就像抱怨“heap”字面意思不是一堆杂乱无章或“queue”不是让排队等候的人买票。许多/大多数计算机科学术语都是类比。

也就是说，另外两个合理的术语是“map”（因为它是从键到值的映射）和“table”（因此，“hash table”，一个用散列实现的表）。

Java实际上使用术语“map”（以及“dictionary” - 稍后当他们意识到字典应该是一个接口时添加了Map，但由于该名称已经被使用了不得不想出一个新名字。）

“表格”的缺点是很容易与the database term混淆。

Answer 3

  

他们唯一模糊的关联   用“字典”这个词就是那个   像人一样执行“查找”   用纸质词典（就像   称呼他们的好理由   “电话簿”）。

查找怎么样？

Answer 4

地图和哈希也有其他含义，这有点混乱。

我正在考虑在现实生活中你会怎样称呼这样的东西。假设您有一百万部电影需要关键和整理。您可以通过在目录或数据库中查找来查找特定电影的位置。图书馆还使用目录来组织书籍。虽然在计算机科学中仍然可能与该术语的其他用法存在一些混淆，但就像表（http://en.wikipedia.org/wiki/Database_catalog）一样，我认为目录或目录是准确的和查找表的表达术语。

Answer 5

您提到您不想使用“哈希表”，因为它将它与给定的实现联系起来。但这一定是件坏事吗？开发代码的人会关心你的类字典语言构造是否具有类似哈希表的性能特征，而简单地将其称为哈希表是最清晰的通信方式。

但是，如果你真的要有一个通用接口，然后是特定的实现（比如Java有Map接口，然后是HashMap和TreeMap），那么我同意付费的书呆子，“地图”可能是最好的选择。

Answer 6

Map是一个很好且准确的名称，正如a paid nerd所建议的那样。

我也喜欢Lua使用的名字Table。

Answer 7

在Python中，词典正式是映射的唯一示例。

不难看出有人可能会争论什么是合理的称为“映射”，例如在数学中，函数总是映射。我想我们可以使用__getitem__()映射调用任何内容，其中还包括序列类型，例如list。

但请注意，有一个official definition（强调我的）：

  

映射：容器对象（例如dict）   它支持任意键   使用特殊方法查找   __getitem__()。

所以，为了回答你的问题，我建议映射或映射。

Answer 8

AssociationCloud

MapCloud

云，因为它是无序的。模糊不清。

Answer 9

“列表”是否意味着订购？不是在现实世界中 - 购物，清单，待办事项清单，清单......没有订购，它们只是写成they occur to the list writer的东西。

您选择的任何单词都不可避免地会与日常使用和/或与专业IT使用的关联发生冲突。所以，如果你真的想要一个更好的词，你需要一个新的比喻，而不是试图重新定位其他语言的名字。那么Rack怎么样？还是IndexedBag？ KeyPairStash？

Answer 10

也许这是我的Perl背景，但我更喜欢哈希。 ＃看，符号看起来像哈希的样子。如果你有哈希哈希。只是我的主观2美分。 ＆LT;耸肩＆GT;

[编辑]

想想板块哈希。好东西，不是罐头。用大块的土豆，洋葱，辣椒，也许是一些咸牛肉。乍一看，它看起来像一大堆美味的随机食物。但是经过检查，你可以命名这些部件。这是一种类型，天气你可怜的番茄酱或在它上面放一些鸡蛋。现在想想玛莎斯图尔特的蔬菜托盘。一切都是很好的蔬菜清单。你可以把它浸在牧场或腐殖质中或堆放在盘子上。天啊，你可以把一些西红柿放进哈希。

这些是类型。这是一种组织数据的方式，建议如何处理它，但与它是分开的，恕我直言。

地图在我看来更像是一种行为，而不是一种类型。这是如何吃食物或更好的食物如何到达你的嘴。

最后，它只是一个名字。

Answer 11

我觉得我会选择“索引”或“KeyedIndex”，“KeyIndex”......

编辑： 哈哈DIYIndex！或者也许我对dict的错误有了全部的想法？

Answer 12

据我所知，jinx是......在本质上有一些具有KEY VALUE关系的联想，我们正在寻找带出相同SENSE的词......所以如果要说出来我会称之为AssociateKVMap ....但听起来并不那么酷....所以让我得到更多的选择

Answer 13

好imho。

Assoc
Array
Dict
Hash
Index
KeyValue
Map
Table

Bad imho。

NSMutableDictionary
hash_map

Answer 14

基本上它们是带有键索引器的列表。你可以调用KeyValuePairCollection。