对类型化记录的字段访问不会保留类型

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报告）