问题
- 许多Java API依赖于扩展抽象基类而不是接口
- "proxy"有局限性(无法访问受保护的字段或超类)
- "proxy"因为多一层函数/参数装箱等,所以性能开销较大
- "gen-class"功能复杂,并与编译/字节码生成相关
总结:Clojure目前还没有一个好的/方便的方法来动态扩展Java抽象基类。
提议创建一个“reify”的变体,允许扩展单个抽象基类(可选地还可以扩展接口/协议)。代码生成将在Java中直接扩展抽象基类的情况下发生(即具有对受保护成员的完全访问权限,并且具有完全类型提示的字段)。
由于这是一个仅适用于JVM的结构,因此它不应影响Clojure的可移植扩展方法(deftype等)。我们建议将其放入独立的命名空间中,这可能成为其他JVM特定互操作功能的家,例如“clojure.java.interop”
建议解决方案: 附加补丁提出了该功能的实现方案,提供一个包含defclass
和extend-class
宏的clojure.interop
命名空间。
`
(defclass name [fields*] options super-class super-args specs)
与clojure.core/deftype
类似,但可以扩展具体类,覆盖
和调用在超类或
其基类中定义的公共和受保护方法,并访问/设置这些的公共和受保护字段。
super-args是一个(可能为空)向超类构造函数传递的参数向量
构造函数的参数
可以通过的类型提示参数this
为超类来调用重写的方法:(.(^SuperClass this method args*)
)
(extend-class options super-class super-args specs)
与clojure.core/reify
类似,可以扩展具体类,覆盖
`
并将参数this
作为超类:(.(^SuperClass this method args*)
)
补丁: 0001-CLJ-1225-add-defclass-extend-class-v2.patch
和调用在超类或
其基类中定义的公共和受保护方法,并访问/设置这些的公共和受保护字段。
super-args是一个(可能为空)向超类构造函数传递的参数向量
构造函数的参数
可以通过的类型提示参数this
为超类来调用重写的方法:(.(^SuperClass this method args*)
)
(extend-class options super-class super-args specs)
请求
jira