将 Erlang 记录作为函数参数传入有什么缺点吗？答案

【问题标题】：Are there any downsides to passing in an Erlang record as a function argument?将 Erlang 记录作为函数参数传入有什么缺点吗？
【发布时间】：2010-02-22 16:13:02
【问题描述】：

将 Erlang 记录作为函数参数传入有什么缺点吗？

【问题讨论】：

您能否将我发送到您为此找到的链接然后@gleber，因为我找不到它？
在google中输入“erlang records”显示erlang.org/doc/reference_manual/records.html排在第4位。此页面包含有关内部表示的信息以及在使用记录时需要有记录定义的信息。这应该足以推断出答案
嗨@gleber，再次 :) 您的 cmets 实际上使 stackoverflow 值得一游，因为您对计算机充满热情，我喜欢这样！无论如何，您能否解释一下如何推断出从那一页给出的答案，因为当前的两个答案都不同？两者都对我有用。我认为@Dustin 的回答也有其优点
记录只是运行时的元组，所以“没有缺点”。记录是编译时的生物，所以“......除非用记录的不同'版本'编译”，例如元组的大小不匹配。 @Dustin 的观点是基于经验的，所以不能从手册中推断出来。你让我来了 :) 使用 proplists 比将大量（通常是可选的）参数传递到 API 的记录要好得多
@gleber，实际上，自从我发布此内容后，我最终使用了 proplists，是的，我同意记录和编译时版本的问题。无论如何，“proplists”看起来真的很“干净”。谢谢

标签： erlang record

【解决方案1】：

没有缺点，除非调用函数和被调用函数是用不同的“版本”记录编译的。

【讨论】：

是的，当然，因为它们是编译时特性。那么将记录用于客户端 API 可能不是一个好主意？
不，我认为在您使用正确版本的 .hrl 文件时使用记录很好。它广泛用于第三方模块和应用程序以及一些核心模块。

【解决方案2】：

erlangs 标准库中的一些函数确实在其接口中使用记录（我现在不记得是哪些，但有一些），但在我看来，主要的关闭是用户必须包含您的头文件，才能使用您的功能。

这对我来说似乎是 unerlangy（你通常不会这样做，除非你使用 stdlib 中的上述函数），创建奇怪的相互依赖关系，并且更难从 shell 中使用（我不会我不知道如何从 shell 加载和使用记录——我通常只是通过手动构建元组来“作弊”......）

此外，处理记录与您通常执行的操作有些不同，因为默认情况下，它们的键将原子“未定义”作为值，这与您通常使用 proplist 处理的方式相反（例如， 't set just 不存在）——这可能会给那些通常不经常处理记录的人带来一些困惑。

所以，总而言之，我通常更喜欢 proplist 或类似的东西，除非我有充分的理由使用唱片。不过，我通常使用记录来记录例如 gen_server 或 gen_fsm 的内部状态；这样更新会更容易一些。

【讨论】：

【解决方案3】：

我认为最大的缺点是它不是惯用的。您是否见过需要您构建记录并将其传入的 API？

为什么你想做一些让任何 erlang 程序员都觉得陌生的事情？对于函数的可选命名参数，已经有一个约定。没有正当理由发明另一种方法是没有意义的。

【讨论】：

只要一个函数的返回值是一条记录，为什么不能作为另一个函数的输入呢？