Question

在语言设计界，曾经有过一场关于语言是否应该使用structural equivalence或name equivalence的长期争论。像ALGOL或ML或Modula-3这样的语言使用结构等价，而......很多，大多数编程语言都采用命名等价（包括Modula-2）。

支持结构等价的典型论据是什么？反对它的典型论点是什么？支持名称对等的典型论据是什么？反对它的典型论点是什么？

Answer 1

我认为结构类型系统的优势在于它们鼓励您创建面向接口用户需要的细粒度接口，而不是实现者提供的接口。

在主格类型系统中，您需要对界面有共同的依赖关系。在结构类型系统中，要求被消除：您可以构建一个松散耦合的系统，而无需创建放置所有接口的公共库。每个客户端都可以独立地从协作者声明它期望的接口。

结构类型系统的缺点是它们将类与接口匹配，这可能无法真正实现正确的合同。例如，如果您有此界面：

public interface IBananaProvider
{
   /// Returns a banana, never null.
   Banana GetBanana();
}

然后将隐式地考虑以下类在结构类型系统中实现IBananaProvider。但是，该类违反了返回的banana永远不为null的post条件：

public class SomeBananaProvider
{
    // returns a banana or null if we're all out
    public Banana GetBanana()
    {
        if (bananas.Count > 0)
        {
            return bananas.RemoveLast();
        }
        else
        {
            return null;
        }
    }
}

如果合同以某种方式正式指定并被视为类型结构的一部分，则可以修复此问题。我认为事情正朝着这个方向发展，例如.NET 4.0中的System.Diagnostics.Contracts。

Answer 2

支持严格名称等效的一个好的论据（例如，在Ada中可用）是它使编译器可以拒绝意外混合不同单位的代码，例如厘米和英寸，或摄氏和华氏。

在具有严格名称等效性的语言中，您可以使用两种类型

type celsius based on float;
type fahrenheit based on float;

var c : celsius; var f : fahrenheit;

c := f; /* compile time error: incompatible types */

然而，在一种失去名称等同性的语言中，在一种具有结构等同性的语言中......

type celsius is float;
type fahrenheit is float;

c := f; /* no error and no warning here */

...你最终会导致错误的计算，导致不可预测的行为，这取决于应用程序和系统的类型，这可能导致严重的经济损失甚至死亡。如果没有严格的名称等同，这样的逻辑错误也很难追踪。

赞同和反对名称对等和结构等价的论据是什么？

2 个答案: