更易发现已废弃的命名空间/变量

Question

来自邮件列表http://groups.google.com/group/clojure/msg/c41d909bd58e4534。在不了解自己的情况下，很容易使用已废弃的命名空间或变量。文档警告很小，也没有编译器警告。

**建议：**

**添加新的{{*\*warn-on-deprecated*\*}}动态变量，默认为false
**当加载{{{:deprecated true}}}命名空间时警告到stderr。
**当分析{{{:deprecated true}}}变量时警告到stderr。
**当展开{{{:deprecated true}}}宏时警告到stderr。
**新的系统属性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

**问题：** 弃用警告的默认值是否应为true？升级的用户可能会看到新的警告，这可能令人惊讶。

**应默认警告还是不警告已废弃的内容？

Answer 1

评论者：richhickey

我不介意警告到stderr

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 lint工具报告已弃用的Clojure函数调用，以及已弃用的Java方法调用。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'和类似工具处理，我更希望限制废弃警告仅针对我的代码，或许可以通过命名空间前缀实现，因为编译器从某个角度考虑，从jar包中读取可能不方便。