结构分型的（缺点）

我刚刚看过Daniel Spiewak的演讲，他谈到了结构化类型与Scala的ans Java 标称类型相比的优势。这种差异的一个示例是以下Java代码

public interface Foo {
  public int length();
}
public interface Bar {
  public int length();
}

Foo f = ...;
Bar b = f;

当然不会编译哪个，因为Foo和之间的类型兼容性Bar由名称决定。

另一方面，结构类型系统可以声明两种类型相等或兼容，因此，除其他事项外，还可以进行检查的鸭子类型。

现在，我认为我确实了解结构类型系统的大多数优点，但是我想知道它是否不会从以下示例中使类型安全失效

class Foo {
  class Bar { /* ... */ }
  def takeBar(b: Bar) = { /* ... */ }
  def getBar: Bar = new Bar
}

val foo1 = new Foo
val foo2 = new Foo
foo1.takeBar(foo1.getBar) // should compile
foo1.takeBar(foo2.getBar) // should not compile

我的理解是正确的，在结构类型系统中，最后一行也可以编译，如果这样，这在类型安全方面是否不利？

实际上，路径相关类型与结构类型与标称类型正交。目前还不清楚内部类在简单的结构化语言中的含义。但是，很有可能对此进行定义。如果要在结构化类型的上下文中定义内部类，则需要确保将拒绝列出的情况（与Scala拒绝它们的原因完全相同）。

您将通过做与Scala相同的事情来拒绝此类情况：将依赖于路径的类型建模为存在类型。围绕对象访问的相同打包/解压过程将保持不变，并且结果看上去几乎与Scala所做的相同。结果可能看起来像是名义上的类型相等，但由于类型兼容性问题仍将由接口而不是名称决定，因此它仍将是结构类型系统。

结构化类型确实有很多含义，但是（也许令人惊讶），我们都从名词类型系统中了解和喜爱的大多数相同概念的确会带入结构化。结构化类型不过是定义类型兼容性的另一种方式。

结构化类型使编写通用库代码更加容易。Java生态系统如此肿的第一大原因是因为很难轻松编写小型库。如果以结构化方式键入Java，我认为那将是另一回事，情况会好得多。

我能想到的关于结构化类型的唯一缺点是编译速度较慢。我不确定结构性语言的编译速度通常是否比名义性语言慢，但是例如Golang是结构化类型的，并且编译速度非常快。