何时在 Elm 中使用类型别名与单值联合类型答案

【问题标题】：When to use type alias vs. single-value union type in Elm何时在 Elm 中使用类型别名与单值联合类型
【发布时间】：2017-07-08 14:15:54
【问题描述】：

我一直在阅读Richard Feldman's Elm SPA app example，我看到很多examples 是这样的：

type Username
    = Username String

我不确定何时使用类似的东西有意义，单值联合类型，而不是像这样的类型别名：

type alias Username
    = String

什么时候适合使用单值联合类型而不是只使用类型别名？

【问题讨论】：

您展示的示例称为不透明类型。使用一个可以让您对程序的其他部分隐藏实现细节（或者在库的情况下，对消费者隐藏）。您可以在Elm package help 中阅读更多关于它们的信息（请参阅标题为“将标签和记录构造函数保密”的部分）。

【解决方案1】：

对于何时合适，没有硬性规定，但我倾向于遵循一些经验法则。让我们使用一个使用用户名和密码的身份验证函数示例，这两个都是字符串值。

在没有任何额外别名或类型的情况下，注释可以是这样的：

authenticate : String -> String -> Bool

鉴于该注释，不清楚哪个参数是用户名，哪个是密码。我们可以通过使用类型别名来提高可读性：

type alias Username = String
type alias Password = String

authenticate : Username -> Password -> Bool

这对我的包的消费者来说更好，但类型别名不会阻止您在调用代码中意外交换参数。例如，这个有问题的函数会编译：

login : Username -> Password -> Bool
login username password =
    if authenticate password username then ...

如果你想更进一步，每次使用时都强制显式声明类型，你可以避免这种类型的错误，因为编译器会捕获混淆：

type Username = Username String
type Password = Password String

使用该定义，您现在必须在每次使用时将字符串显式解包并打包到 Username 或 Password 构造函数中。这对于像度量单位这样的东西特别有用，这样的概念可能有avoided the loss of a Mars mission

正如您在 Richard 的示例中看到的，走完整类型和类型构造函数的路线意味着您需要单独的样板函数来进行 json 解码、编码等，这可能会变得乏味。您需要为您的团队和项目找到合适的平衡点。

【讨论】：