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

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： "你应该始终根据协议或接口编程 -
数据类型不能公开其协议或接口之外的方法"

沿着这条线，通常对于deftype，如果有必要，我会生成一个具有正确类型的接口，然后让deftype实现接口以公开字段。

同样根据https://clojure.org/datatypes

"请注意，目前非基本类型的类型提示将不会用于约束字段类型或构造函数参数，但将用于优化其在类方法中的使用" - 即，在记录/类型的实现方法内部，引用字段应该有正确的提示。因此，在上面的示例中，如果unwrap是记录或协议实现方法，并且你引用了字段，你应该期望在那个场景中将提示利用起来。

因此，我认为这个工单中描述的所有行为都应根据设计预期，这就是为什么我将这个工单重新分类为增强功能，而不是缺陷。

Answer 4

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