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

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 group的最新电子邮件线程。链接：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等效，可能更易读。如果 preferred，我很乐意发送它。

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中的(test/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包的警告浪潮所淹没吗？更糟的是，这场浪潮可能持续数周或数月，直到相应库的作者们能够跟进。由于jars可以通过'lein ancient'等工具来处理（更有效率），我更希望只对我的代码中的弃用警告进行限制，也许可以通过命名空间前缀，如果从JAR包中编译时的不便从编译器的角度来看的话。