使已弃用的命名空间/变量更容易被发现

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 : 变量 #'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 提出

我在 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](https://github.com/jonase/eastwood)

Answer 10

评论者：alexmiller

我对将其考虑为Clojure 1.9感兴趣，但我需要一些帮助来准备它。我对当前状态的评论如下：- 需要更多关于当前方法的详细信息

• 我喜欢 } 而非，因为它回显了您用于标记废弃变量的关键字
• 警告信息没有告诉您位置，这是grr - 应该类似于反射信息
• 需要测试 - 请参阅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中编译不便利的话，或许可以通过命名空间前缀来实现。