使弃用的命名空间/变量更容易识别

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 : 变量 #'user/f 已弃用

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

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


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

*问题：* 弃用警告的默认值应为 true 吗？升级的人可能会看到新的警告，可能会令他们感到惊讶。

*弃用默认是否应警告或不应警告？

Answer 1

评论由：richhickey 制作

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

Answer 2

评论文本：lvanderhart

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

Answer 3

评论文本：jafingerhut

非常好。我查看了第一个补丁，但没有看到任何允许通过命令行禁用废弃警告设置的东西，就像现在的 warn-on-reflection 可以通过命令行选项设置为 true 一样。

这是否对于废弃警告非常重要？

Answer 4

评论文本：jafingerhut

我希望快速简单地向废弃警告消息中添加源文件、行和列信息。这并不像添加到格式()调用那样简单，因为 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](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 本身也有一些已弃用使用的实例 - 在补丁中清理这些实例会很好。可能需要单独的补丁来处理，这取决于它们是否容易修复。如果 test/ 中的某些情况实际上是应该保留的，可以在该名称空间中将 * } 设置为 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文件或不是的话不方便。