为什么结构化类型的编译时生成技术会阻止单独编译?
我正在阅读(好的,略读)Dubochet和Odersky在JVM上编译结构类型,并对以下声明感到困惑:
生成技术创建了Java接口
对于JVM上的结构类型。这种复杂性
技术在于所有要用作的类
程序中任何地方的结构类型都必须实现
正确的界面。当它在编译时完成时,它
防止单独编译。
(重点补充)
考虑论文中的autoclose示例:
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
,我们需要生成一个包装器:
class FileInputStreamAnonymousInterface1Proxy(val self: FileInputStream)
extends AnonymousInterface1 {
def close() = self.close();
}
object FileInputStreamAnonymousInterface1Proxy {
implicit def fis2proxy(fis: FileInputStream): FileInputStreamAnonymousInterface1Proxy =
new FileInputStreamAnonymousInterface1Proxy(fis)
}
我必须遗漏一些东西,但我不清楚它是什么。为什么这种方法会阻止单独编译?
没有找到相关结果
已邀请:
3 个回复
盟犯涩沟都
容淑阔九
功飘
程序中的某些位置,可能在单独编译的库中,使用此结构类型:
和其他地方一样,这个用于:
除了全局分析之外,如何使用必要的接口来装饰A类,以便在指定那些偏远的结构类型的地方使用它们? 如果给定类可以遵循的每种可能的结构类型用于生成捕获该结构类型的接口,则会出现这种接口的爆炸式增长。请记住,结构类型可能会提到多个必需成员,因此对于具有N个公共元素(val或defs)的类,这些N的所有可能子集都是必需的,并且这是N的powerset,其基数为2 ^ N.