2024 年 Clojure 调查中分享你的想法!

欢迎!请查看 关于页面,了解更多有关此页面的信息。

0
Java互通
编辑

我经常发现自己通过放置类型完全明确的注解来处理反射警告。

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

"bar" 是一个 String,这一点在编译时就可以明确知道,这似乎意味着我在做粗活,也可能后来会过时。

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

(“类型推断”可能对这个用例来说是一个夸张的术语)

...我想至少有一个反对意见:(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,代码可能会以多种方式被破坏。

也许这个功能可以通过动态变量或系统属性来控制,对于那些关心这个(并且不会手搓代码)的人来说。
我们当然不会反对在可能的情况下添加类型推断,但这个特定的更改既非微不足道也不太可能因为类型提示的有效性而获得支持。话虽如此,Typed Clojure 项目可能对这个场景有一个令人满意的解决方案,这值得探索。 https://typedclojure.org
...