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

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

+5
错误
来自邮件列表 http://groups.google.com/group/clojure/msg/c41d909bd58e4534。忽略你正在使用弃用的命名空间或变量是很容易的。文档警告很小,而且没有编译器警告。

**提议:**

**增加新的 {{\*warn-on-deprecated*}} 动态变量,默认为 false**
**当加载具有 {{:deprecated true}}} 标识的命名空间时,向标准错误输出警告**。
**当分析具有 {{:deprecated true}}} 标识的变量时,向标准错误输出警告**。
**当扩展具有 {{:deprecated true}}} 标识的宏时,向标准错误输出警告**。
**新的系统属性 clojure.compiler.warn-on-deprecated**
**使用 clojure.compiler.warn-on-deprecated 编译 Clojure 本身**
**修复Clojure内部的弃用警告(replicate、clear-agent-errors)**
**使用:deprecation 标签标记 clojure.parallel 为弃用**

**示例**


(set! *warn-on-deprecated* true)

;;弃用变量的使用(在编译时)
(defn ^:deprecated f [x] x)
(f 5)
;;=> 弃用警告,NO_SOURCE_PATH:7:1 : var #'user/f 是弃用的

;;弃用宏的使用(在宏扩展时)
(defmacro ^:deprecated m [x] x)
(m 5)
;;=> 弃用警告,NO_SOURCE_PATH:7:1 : macro #'user/m 是弃用的

;;弃用命名空间的使用(在加载时)
(ns foo {:deprecated "1.1"})
(ns bar (:require foo))
;;=> 弃用警告:从命名空间 `bar` 加载已弃用的命名空间 `foo`


**补丁:** 706-deprecated-ns-var-warnings-tested-3.diff

**问题:** 弃用警告的默认值应该是 true 吗?升级的用户可能会看到新的警告,可能令人惊讶。

**默认值应该是警告还是不警告弃用?**

25 个回答

0

评论者:richhickey

我不介意向标准错误输出警告

0

评论作者:lvanderhart

706-deprecated-var-warning.diff 插件在使用废弃变量时添加警告。其他三个补丁清理了废弃警告。

0

评论作者:jafingerhut

非常好的东西。我查看了一下第一个补丁,但没有看到如何从命令行禁用废弃警告的内容,就像今天可以通过命令行选项将 warn-on-reflection 设置为true一样。

这对于废弃警告是否很重要?

0

评论作者:jafingerhut

我希望快速和简单地添加源文件、行和列信息到废弃警告消息中。这不是在 format() 调用中添加它们的那么简单,因为 analyzeSymbol 方法不会接收这些值作为参数。这个废弃检查是在不容易关联到源文件、行和列的地方进行的吗?它是否可以在这些信息容易获得的地方进行?

0

评论作者:gshayban

另一个补丁——这次是在加载废弃命名空间时发出警告,而不是变量。此补丁需要第一个补丁。

关于行/列,如果需要,我会想办法传递编译上下文。

关于编译标志。我也有一个补丁,但我还在验证如何调用。怎么通过命令行设置 warn-on-reflection?

0

评论作者:jafingerhut

关于编译标志。如果你想实现标志,就别推迟,但也许值得听听别人的意见,看看是否真的需要这样的命令行选项。我曾希望引出这样的回应。

关于Clojure编译器中对其的处理方式,请搜索Compile.java中相关的REFLECTION_WARNING_PROP代码。如果您通过Java命令行直接调用Clojure编译器,请使用-Dclojure.compile.warn-on-reflection=true(默认为false)。如果想知道如何通过ant或Maven来实现,请查看发送到Clojure Dev Google组的最近邮件thread。链接:https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3

还有一个名为compiler-options的单独命令行标志(见Compile.java),它在编译器内部实现为映射。它比warn-on-reflection添加的时间要晚,可能是添加更多此类选项的首选方法,以避免需要在多个地方的pushThreadBindings调用中继续添加更多参数。

0
by

评论作者:gshayban

谢谢,Andy。

对于最后的ns补丁,调用(print-method msg err)与其说是将out绑定到err,可能更易读。如果更合适,我将乐意提供。

0
by

评论作者:jafingerhut

2013年2月12日的706-deprecated-var-warning-patch-v2.txt与2012年10月26日的706-deprecated-var-warning.diff相同,除了它干净地应用到最新的master。

0
by

评论作者:jafingerhut

对于检查此票箱并希望此功能的人员的信息,Eastwood lint工具报告了对已过时的Clojure函数的调用,以及对已过时的Java方法的调用。https://github.com/jonase/eastwood

0
by

评论者:alexmiller

我对考虑Clojure 1.9但需要一些帮助使其准备的方案感兴趣。我对当前状态的以下评论:- 票需要更多关于当前方法的细节

  • 我更喜欢因为这与您用于标记已过时变量关键字相同。
  • 警告消息没有告诉你位置,这是grr - 应该类似于反射消息。
  • 需要测试 -参见test/clojure/test_clojure/compilation.clj和test/clojure/test_helper.clj中的(should-not-reflect)示例
  • clojure自身也有一些已过时使用的示例 - 在补丁中清理这些示例会很好。这可能需要一个单独的补丁,具体取决于它们是否容易修复。如果test/中有实际可以留下的情况,可以在这個namespaces中设置*为false。
  • 当前默认设置为true - 可能应该改为false,以匹配反射警告的默认设置。
0

评论者:vijaykiran

(链接:~alexmiller) 我可以尝试一下。

0

评论者:alexmiller

嗨Vijay,Andrew Rosa已经把自己分配了这个任务,所以请和他协调,因为他已经开始工作了。

0

评论者:bozhidar

只有一个小备注——默认启用弃用警告不是更常见吗?可能会认为这对于代码在未来可能会因未注意到正在使用弃用功能而撞到破坏,因此更为重要。

0

评论者:alexmiller

(链接:~bozhidar) 我有些犹豫。我之所以犹豫将其设置为默认,是因为人们可能会突然有大量新的警告(我认为这可能是好是坏)。这取决于我们有多强烈地希望人们关注弃用问题。

0

评论者:pbwolf

默认关闭的弃用警告没有解决此票据中给出的第一个和主要问题:“很容易在不知道的情况下使用弃用命名空间。”

这与反射警告不同。你可以随时专注于速度,随意。但最终删除有风险的功能将是一个突然的、令人不愉快惊喜;警告会有所帮助。

但——假设我写了300行Clojure并使用了来自jar上的一百万行代码。我的代码中的弃用问题会被埋没在那些jar的大量警告中吗?更糟糕的是,这场海啸可能会持续数周或数月,直到库的各自作者赶上。在jar被覆盖(更加迅速)的情况下,我更愿意能够限制弃用警告只针对我的东西,也许可以通过命名空间前缀,如果从编译器视角看从jar中启用不方便。

...