支持和反对名称等价和结构等价的论点是什么?

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

在指定类型系统中,您需要对接口有一个共同的依赖关系。在一个结构类型系统中,这种需求被消除了:您可以构建一个松散耦合的系统,而无需在放置所有接口的地方创建公共库。每个客户机都可以独立地声明它期望从合作者那里得到的接口。

结构类型系统的缺点是,它们将类与接口匹配起来,这些接口可能无法真正实现正确的契约。例如,如果您有这个接口:

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

那么下面的类将被隐式地视为实现 IBananaProvider 在结构型系统中。但是,类违反了返回的Banana从不为空的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;
        }
    }
} 

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

一个支持严格名称等效(例如在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 */

…您最终会导致计算错误,从而导致不可预测的行为,这取决于应用程序和系统的类型,这可能会导致严重的财务损失甚至死亡。如果没有严格的名称等效性,这种逻辑错误也很难被跟踪。