关于类型别名/同义词的想法？

10

我将尽最大努力以不会导致语言冲突或语言清单的方式来构架此问题，因为我认为对此问题可能会有很好的技术答案。

不同的语言在不同程度上支持类型别名。C＃允许在每个代码文件的开头声明类型别名，并且它们仅在整个文件中有效。像ML / Haskell这样的语言使用类型别名的次数可能与使用类型定义的次数一样多。C / C ++有点像狂野的西部，typedef并且#define经常与别名类型互换使用。

类型别名的优点不会引起太多争议：

可以方便地定义由语言自然描述的复合类型，例如type Coordinate = float * float或type String = [Char]。
长名可以缩写：using DSBA = System.Diagnostics.DebuggerStepBoundaryAttribute。
在像ML或Haskell这样的语言中，函数参数通常没有名称，类型别名提供了类似自我文档的形式。

不利之处在于：别名会大量增加，从而使阅读和理解代码或学习平台变得困难。Win32 API就是一个很好的例子，包括它DWORD = int，它HINSTANCE = HANDLE = void*和它的LPHANDLE = HANDLE FAR*等等。在所有这些情况下，区分HANDLE和void指针还是DWORD和整数等几乎没有任何意义。

抛开哲学上的争论，即国王是否应该给予臣民完全的自由，让他们自己负责，或者是否应该干预所有可疑的行为，是否有一种快乐的媒介可以允许类型混叠的好处，而减轻滥用风险？

例如，长名称问题可以通过良好的自动完成功能来解决。例如，Visual Studio 2010将允许您键入DSBA，以便将Intellisense引用到System.Diagnostics.DebuggerStepBoundaryAttribute。还有其他功能可以更安全地提供类型别名的其他好处吗？

programming-languages

— 宫阪丽
source

不管是否进行智能感知，System.Diagnostics.DebuggerStepBoundaryAttribute在代码中的可读性都比DSBA低得多，尤其是在经常使用时。

— zvrba 2011年

@zvrba：实际上DebuggerStepBoundaryAttribute比更具可读性DSBA。在第一种情况下，您知道这意味着什么。在第二篇中，您不知道。现在，假设您在代码中使用了二十个这样的别名。会有人有足够的勇气尝试阅读和理解您的代码吗？

— 阿森尼·穆尔琴科

3

我想到两个功能：

可移植性。在像C这样的语言中，像这样的数据类型int是特定于平台的，使用别名这样的别名DWORD可以更轻松地确保您确实在任何地方都使用32位带符号整数，即使这是您程序的要求，即使您将程序移植到平台int是例如16位无符号，因此DWORD必须是的别名signed long。

抽象。在您的程序中，您可能出于不同的目的使用大量的整数和浮点数。通过像创建别名SPEED，HEIGHT，TEMPERATURE，这是比较容易改变那些例如，从一个float到double，离开别人，因为它们。

— 用户名
source

但这并不能回答问题……

— 宫阪丽

@Rei，您说得对，ammoQ并未回答问题，但确实对此发表了评论。尽管如此，P.SE不允许格式化或冗长的评论……我认为他不应该被否决：他的评论是关于话题的，也是不错的评论。

— 安藤（Ando）

@Andrea似乎不是全部阅读问题的结果；除了关于可移植性的说明（这只是要列出的缺点中的另一项内容）之外，这只是重述。

— 宫阪丽

2

我同意Andrea，您需要封装，但是我不同意这样做需要昂贵的费用。

我认为Happy介质将是类型安全的typedef，可以允许在实类型和typedef之间进行显式转换，但可以防止隐式转换。

也就是说，我在许多语言中看到的typedef的主要问题是它们实际上并没有引入新类型，而只是引入了别名，尽管这很有用，但它不像新类型那样有用，就像旧类型一样，但是新名称。如果只想确保不要混用几个变量，那么组合或继承就太繁琐了。

— jk。
source

1

我完全同意，我真的很想看到这种“有限的”多态性。如果为type Name = String，则String不能将a传递给预期为a的函数Name，但相反的情况也是可能的。

— Matthieu M.

1

我认为类型别名给懒惰的程序员（非常）便宜的封装。因此，替代方案可能只是使用适当的（昂贵的）封装。

还有一种观点认为，尽管前者在使用的机器/语言方面也比后者更为优化。

— 安藤
source