在类型化记录中对字段进行访问不保留类型

Question

`
(ns field-test.core
(:import [java.util UUID]))

(defrecord UUIDWrapper [^UUID uuid])

(defn unwrap [^UUIDWrapper w]
(.-uuid w)) ; <- 没有反射

(defn get-lower-bits [^UUIDWrapper w]
(-> w .-uuid .getLeastSignificantBits)) ; <- 反射 :(
`

编译器似乎已经拥有所需的所有信息，但 lein check 打印

反射警告，field_test/core.clj:10:3 - 无法解决对 java.lang.Object 的 getLeastSignificantBits 字段的引用。

(测试案例也位于 https://github.com/MichaelBlume/field-test)

Answer 1

评论者：alexmiller

我认为，在记录字段上使用的 ^UUID 类型提示没有任何作用。记录字段将具有 Object 类型（只有 ^double 和 ^long 会影响实际字段类型）。

也许更重要的是，使用 Java 互操作来检索记录的字段值是不良的做法。首选按键访问。

Answer 2

评论者：bronsa

对于没有按键访问选项的 deftypes，也存在相同的问题。

Answer 3

评论者：alexmiller

根据 https://clojure.org/datatypes：“您应该始终针对协议或接口进行编程 -
数据类型不能公开协议或接口中没有的方法

沿着这个思路，通常对于deftypes，如果需要，我会生成一个具有适当类型的接口，然后让deftype实现接口以公开字段。

另见 https://clojure.org/datatypes

"请注意，当前非原始类型的类型提示不会用于约束字段类型或构造函数参数，但会用于优化其在类方法中的使用" —— 这意味着在一个在记录/类型上实现的方法内部，引用字段应具有正确的提示。因此，在上面的示例中，如果unwrap是记录的接口或协议实现方法，并且你引用了字段，你应该期望在那种情况下使用该提示。

因此，我的观点是，根据设计，可以预期在这份工单中描述的所有行为，这就是为什么我将它重新分类为增强，而不是缺陷。

Answer 4

参考： https://clojure.atlassian.net/browse/CLJ-1774（由michaelblume报告）