使用关联列表而不是记录是个好主意吗？
有经验的 Erlang 程序员会推荐关联列表而不是记录吗？
一种情况可能是不同机器上的两个（或更多）节点正在交换消息。 我们希望能够独立升级每台机器上的软件。 某些升级可能涉及向正在发送的一条（或多条）消息添加字段。 似乎使用记录作为消息意味着您始终必须以锁定步骤在两台计算机上进行升级，以便额外的字段不会导致接收者忽略该记录。 然而，如果您使用关联列表（仍然具有“类似记录”的 API）之类的内容，则尚未升级的接收器仍将成功接收消息并忽略新字段。 我意识到这并不总是理想的行为，但通常是理想的行为。 另外，假设消息相当小，因此查找时间并不重要。
假设上述内容有一定道理，我还有以下附加问题：
- 是否有一个标准（或广泛使用）的列表库？ 一些琐碎的谷歌搜索没有发现任何东西。
- 是否还有其他情况需要使用关联列表（或类似的东西）？
Would any experienced Erlang programmers out there ever recommend association lists over records?
One case might be where two (or more) nodes on different machines are exchanging messages. We want to be able to upgrade the software on each machine independently. Some upgrades may involve adding a field to one (or more) of the messages being sent. It seems like using a record as the message would mean you'd always have to do the upgrade on both machines in lock step so that the extra field didn't cause the receiver to ignore the record. Whereas if you used something like an association list (which still has a "record-like" API), the not-yet-upgraded receiver would still receive the message successfully and just ignore the new field. I realize this isn't always the desired behavior, but often it is. Also, assume the messages are fairly small so the lookup time doesn't matter.
Assuming the above makes some sense, I have the following additional questions:
- Is there a standard (or widely used) library for alists? Some trivial googling didn't turn up anything.
- Are there other cases where you would use an association list (or something like it)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您基本上有三个选择：
我使用更改可能性非常低的记录。 这样我就可以获得我想要的模式匹配并加快速度。
我在需要类似哈希表的功能时使用 proplists。 我以牺牲模式匹配和速度为代价获得灵活性。
有时我同时使用两者。 具有一个字段（即 proplist）的记录。 这样我就可以对它的一部分进行模式匹配，并且在需要的地方具有灵活性。
所有三种选择都有不同的权衡，因此您基本上只需评估您的特定需求并做出选择。 可能需要一些原型设计和尝试才能弄清楚哪些权衡是有意义的以及哪些功能是您绝对必须拥有的。
You have basically three choices:
I use records where the likelihood of changing it is very low. That way I get the pattern matching and speed up that I want.
I use proplists where I need hashtable like functionality. I get flexibility at the expense of pattern matching and speed.
And sometimes I use both. A record with one field that is a proplist. That way I can pattern match on a portion of it and yet have flexibility where I need it.
All three choices have different trade-offs so you basically just have to evaluate your particular needs and make a choice. It may take some prototyping and playing around to figure out which trade-offs make sense and which features you absolutely must have.
对于少量的键，您可以使用列表，也称为 proplists 对于更大的键，您应该使用字典。 在这两种情况下，最大的缺点是您无法以用于记录的方式使用模式匹配。 还有速度损失，但在大多数情况下是无关紧要的。
For small amount of keys you can use lists aka proplists for bigger you should use dict. In both cases biggest disadvantage is that you can't use pattern match in way as used for records. There is also speed penalty but it is in most cases irrelevant.
请注意，lists:keysearch/3 几乎是“assq”。
Note that lists:keysearch/3 is pretty much "assq".