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

欢迎!请查看关于页面了解这个平台的一些基本信息。

0 投票
Java互操作
编辑

我经常发现自己在针对反射警告进行注释时,类型是完全不言而喻的

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

"bar"是一个String,在编译时已经鲜明可知,所以在我看来,我正在进行一些琐碎的工作,也可能会创建一些后来可能过时的东西。

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

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

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

1 答案

+1 投票

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

没有保证(无论是隐式还是显式)代码不会执行类似(alter-var-root #'foo #(do % 42))的操作,除非有人提供提示。这将使得在核心语言中做隐式类型推断变得困难。

我考虑了这一点,alter-var-root 可以简单地在当前类型可以被推断时删除任何类型注解,而不是程序员指定的(通过附加一些元数据,这种区别似乎是很容易的。)
通过在 alter-var-root 中使用运行时操作来删除类型提示并不能帮助那些已经编译了原始类型信息的代码。
如果以一种无结构的方式重新加载代码(无论选择哪种工作流程)以及/或者使用低级API,代码可能会以许多方式被破坏。

也许这个特性可以通过例如动态变量或系统属性来控制,对于那些关心(并且不会黑客方式加载代码)的人来说。
当然,我们并不反对尽可能地在可能的情况下添加类型推断,但这个特定的改变并不是微不足道的,并且鉴于类型提示的有效性,它可能不会受到广泛关注。话虽如此,Typed Clojure 项目可能对此场景有一个令人满意的解决方案,并且值得探索。[前往Typed Clojure](https://typedclojure.org)
...