更易于识别已弃用的命名空间/变量

Question

来自邮件列表 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 is deprecated

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

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


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

*问题：* 应该默认启用还是禁用弃用警告？升级的用户可能会看到新的警告，可能会感到惊讶。

*默认应该警告或不应警告已弃用？

Answer 1

评论由：richhickey 发布

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

Answer 2

评论由：lvanderhart 撰写

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

Answer 3

评论由：jafingerhut 撰写

太棒了。我查看了一下第一个补丁，但没看到任何能够使人通过命令行禁用废弃警告的内容，就像今天可以通过命令行选项将 warn-on-reflection 设置为 true 一样。

这对废弃警告来说是否很重要？

Answer 4

评论由：jafingerhut 撰写

我希望能够迅速轻松地为废弃警告消息添加源文件、行和列信息。这不是像添加到 format() 调用那样简单，因为 analyzeSymbol 方法并不接收这些值作为参数。这个废弃检查是否是在一个不易将其与源文件、行和列关联的地方进行的？是否可以在一个容易获取这些信息的地方进行？

Answer 5

评论由：gshayban 撰写

另一个补丁——这次是警告加载废弃的命名空间，而不是变量。这个补丁需要第一个补丁。

关于行/列信息，如果需要，我会想办法将编译上下文传递过去。

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

Answer 6

评论由：jafingerhut 撰写

关于编译标志。如果你想要一个标志，不要推迟实现，但如果其他人甚至不希望有这种命令行选项，那么这似乎也很值得听听。我曾询问以激发这样的回应。

关于Clojure编译器如何处理，请在 Compile.java 中搜索 REFLECTION_WARNING_PROP 和相关代码。如果你直接通过Java命令行调用Clojure编译器，使用 -Dclojure.compile.warn-on-reflection=true（默认为false）。如果你想知道如何通过ant或Maven执行，请参阅最近发送给Clojure Dev Google组的电子邮件线程。链接：[https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3](https://mail.google.com/mail/?shva=1#label/clojure-dev/13aa0e34530196c3)

还有一个称作 compiler-options 的单独命令行标志（见 Compile.java，它作为编译器内部的映射实现。它比 warn-on-reflection 更晚添加，可能更倾向于添加更多此类选项的方法，以避免需要在多个地方的 pushThreadBindings 调用中持续添加更多参数。

Answer 7

评论由：gshayban 撰写

谢谢，Andy。

对于最后的 ns 补丁，调用 (print-method msg err) 与绑定 out 到 err 相当，可能更易阅读。如果这更可取，我很乐意提供。

Answer 8

评论由：jafingerhut 撰写

2013年2月12日的 706-deprecated-var-warning-patch-v2.txt 与2012年10月26日的 706-deprecated-var-warning.diff 相同，但可以干净地应用到最新的 master 上。

Answer 9

评论由：jafingerhut 撰写

对于任何查看这个工单并希望有这个功能的人来说，Eastwood 工具报告废弃的 Clojure 函数调用，以及其他废弃的 Java 方法调用。[https://github.com/jonase/eastwood](https://github.com/jonase/eastwood)

Answer 10

评论者：alexmiller

我对考虑 Clojure 1.9 的这个功能感兴趣，但需要一些帮助使其准备就绪。我对当前状态的一些评论：- 工单需要更多关于当前方法细节

• 我更喜欢 } 而不是 ，因为它反映了你用来标记废弃变元的词汇
• 警告消息不告诉你位置，这让人很恼火——应该与反射消息类似
• 需要测试 - 查看 test/clojure/test_clojure/compilation.clj 和 test/clojure/test_helper.clj（should-not-reflect）中的示例
• clojure 自身也有一些废弃使用的实例 - 在补丁中清理那些会很好。这可能需要另一个补丁，取决于它们是否容易修复。如果测试中某些情况实际上是保持的，可以在那个命名空间中将 * } 设置为 false。
• 当前默认值为 true - 可能应该改为 false 以匹配反射警告的默认值。

Answer 11

评论：vijaykiran

（链接：~alexmiller）我可以试一下。

Answer 12

评论者：alexmiller

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

Answer 13

评论：bozhidar

只有一个小小的评论——默认启用弃用警告不更常见吗？可以争论它们比反射警告更重要，因为如果你的代码因未注意到使用了弃用功能而在将来被破坏，那么你的代码可能会被破坏。

Answer 14

评论者：alexmiller

（链接：~bozhidar）我有点儿犹豫。我主要犹豫将其设置为默认值是因为人们可能会突然有一大堆新的警告（我想这可能是好是坏）。取决于我们希望人们多么关心弃用（也许）。

Answer 15

评论：pbwolf

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

它不同于反射警告。你可以在任何时候根据自己的兴趣关注速度。但最终移除有风险的特性可能会突然、令人不快的惊喜；警觉是有帮助的。

但是——假设我写了300行Clojure代码，使用了来自jar的一百万行代码。我的代码中的弃用问题会不会被那些jar的警告洪流淹没？更糟的是，这个洪流可能会持续几周或几个月，直到库的相应作者赶上。鉴于jar被“lein ancient”和类似的工具（更高效地）覆盖，我宁愿能够将弃用警告限制在自己的代码中，或许通过命名空间前缀来限制，如果从编译器的角度看 jam-or-not 不方便。