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

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发布

非常好。我看了第一个补丁，里面没有让某人通过命令行选项禁用弃用警告的选项，就像今天的可以设置为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

还有一个单独的命令行标志，称为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文件中提取可能不方便。