为什么结构类型的编译时生成技术会阻止单独编译？

Question

我正在阅读（好吧，略读）Dubochet 和 Odersky 的 在 JVM 上编译结构类型< /a> 并对以下声明感到困惑：

生成技术创建 Java 接口来代替 对于 JVM 上的结构类型。此类的复杂性 技术在于所有要用作 程序中任何位置的结构类型都必须实现 正确的接口。 当这在编译时完成时，它 防止单独编译。

（添加强调）

考虑论文中的自动关闭示例：

type Closeable = Any { def close(): Unit }

def autoclose(t: Closeable)(run: Closeable => Unit): Unit = {
   try { run(t) }
   finally { t.close }
}

我们不能为 Closeable 类型生成一个接口，如下所示：

public interface AnonymousInterface1 {
   public void close();
}

并转换我们的 autoclose 定义 到

// UPDATE: using a view bound here, so implicit conversion is applied on-demand
def autoclose[T <% AnonymousInterface1](t: T)(run: T => Unit): Unit = {
   try { run(t) }
   finally { t.close }
}

然后考虑 autoclose 的调用站点：

val fis = new FileInputStream(new File("f.txt"))
autoclose(fis) { ... }

由于 fis 是一个 FileInputStream，它不实现 AnonymousInterface1< /code>，我们需要生成一个包装器：

class FileInputStreamAnonymousInterface1Proxy(val self: FileInputStream) 
      extends AnonymousInterface1 {
   def close() = self.close();
}

object FileInputStreamAnonymousInterface1Proxy {
   implicit def fis2proxy(fis: FileInputStream): FileInputStreamAnonymousInterface1Proxy =
      new FileInputStreamAnonymousInterface1Proxy(fis)
}

我一定缺少一些东西，但我不清楚它是什么。为什么这种方法会阻止单独编译？

Answer 1

我记得关于Scala-Inernals 邮件列表，问题在于对象标识，它由当前的编译方法保留，当您包装值时会丢失。

Answer 2

想一想。考虑类 A

class A { def a1(i: Int): String = { ... }; def a2(s: String): Boolean = { ... }

在程序中的某个地方，可能在单独编译的库中，使用了这种结构类型：

{ def a1(i: Int): String }

在其他地方，使用了这种结构类型：

{ def a2(s: String): Boolean }

除了全局分析之外，类 A 是如何用允许它的必要接口进行修饰的在指定那些广泛的结构类型的地方使用？

如果给定类可能符合的每种可能的结构类型都用于生成捕获该结构类型的接口，那么此类接口就会激增。请记住，结构类型可能会提及多个必需成员，因此对于具有 N 个公共元素（val 或 defs）的类，需要这些 N 的所有可能子集，这就是基数为 2^N 的 N 的幂集。

Answer 3

我实际上使用您在 Scala ARM 库 中描述的隐式方法（使用类型类）。请记住，这是问题的手工编码解决方案。

这里最大的问题是隐式解析。编译器不会即时为您生成包装器，您必须提前这样做并确保它们是隐式作用域之一。这意味着（对于 Scala-ARM）我们为任何资源提供“通用”包装器，并在找不到合适的包装器时回退到基于反射的类型。这提供了允许用户使用普通隐式规则指定他们自己的包装器的优点。

请参阅：资源类型- Trait 以及所有预定义的包装器。

另外，我在博客中详细介绍了这种技术，更详细地描述了隐式解析魔法：猴子修补、鸭子类型和类型类。

无论如何，您可能不想每次使用结构类型时都手动编码类型类。如果您确实希望编译器自动创建一个接口并为您施展魔法，那么它可能会变得混乱。每次定义结构类型时，编译器都必须为其创建一个接口（也许在以太坊的某个地方？）。我们现在需要为这些东西添加名称空间。此外，每次调用时，编译器都必须生成某种包装实现类（同样存在命名空间问题）。最后，如果我们有两个具有相同结构类型的不同方法单独编译，那么我们就增加了所需接口的数量。

并不是说这个障碍无法克服，但如果您想要对特定类型进行“直接”访问的结构类型，那么类型特征模式似乎是您今天最好的选择。