2024年Clojure状态调查!中分享您的想法。

欢迎!请参阅关于页面,了解更多关于这个工作方式的信息。

0
Java互操作
编辑

我经常发现自己通过放置类型完全明显注释来解决反射警告。

(def ^String foo "bar") ;; adding ^String fixes reflection warnings elsewhere

"bar" 是一个字符串,这是在编译时就可以明显知道的,因此对我来说,这似乎是在做繁重的工作,同时也可能创建出以后可能过时的东西。

有没有考虑过为这样的简单情况添加“类型推断”?

(“类型推断”可能对这个用例有点夸张)

...我可以想到至少一个反对意见:(def ^CharSequence foo "bar")也可以准确且有用。但是,一个好的默认设置是将x的类型推断为x的类,如果用户想将x标注为其祖先之一(在这里:CharSequence,Object),则可以手动覆盖推断的默认值。

1 个回答

+1

(def foo "bar") 创建了一个Clojure变量 - 从技术上说是一种可变的存储形式。

除非有人给出提示,否则不能保证代码不会执行诸如(alter-var-root #'foo #(do % 42))的操作。这将使得在核心语言中进行隐式类型推断变得困难。

图片描述
我考虑过这个问题,如果当前类型已经推断,那么 alter-var-root 可以简单地擦除任何类型注解,而不是程序员指定的(这似乎通过额外的元数据可以很容易地区分。)
图片描述
使用 alter-var-root 中的运行时操作来擦除类型提示并不能帮助那些已经使用原始类型信息编译过的代码。
图片描述
如果以无结构化的方式重新加载代码(无论选择的流程如何)以及/或使用底层API,代码可能以许多方式被破坏。

也许这个特性可以通过例如动态变量或系统属性来控制,这对于我们这些关心(且不会篡改代码)的人来说。
图片描述
我们当然不反对在可能的情况下添加类型推断,但这个特定的变更并不简单,并且鉴于类型提示的有效性,可能不会得到广泛的应用。话虽如此,Type Clojure 项目可能对此场景有令人满意的解决方案,这可能值得探索。 https://typedclojure.org
...