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

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

还有一个名为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本身有一些已过时使用的实例 - 在补丁中清理这些会很好。这可能需要一个单独的补丁，取决于它们是否容易修复。如果在test/中有实际上可以留下来的情况，可以在该命名空间中将*从false设置回true。
• 当前默认值为true - 可能应该为false，以便与反射警告的默认值匹配。

Answer 11

评论由：vijaykiran发表

(链接：~alexmiller) 我可以试一下。

Answer 12

评论者：alexmiller

嗨Vijay，Andrew Rosa自己接受了这个任务，所以请与他协调，因为他已经开始着手工作了。

Answer 13

评论由：bozhidar发表

只是一点小意见 - 是否默认启用弃用警告更为常见？可以说它们比反射警告更重要，因为您的代码可能会在未来因为您没有注意到您使用了已弃用的内容而损坏。

Answer 14

评论者：alexmiller

(链接：~bozhidar) 我处于犹豫不定的状态。我之所以犹豫将其设为默认值，是因为人们可能会突然收到大量新的警告（可能好也可能不好）。这取决于我们有多想让人们关心弃用问题。

Answer 15

评论由：pbwolf发表

默认情况下关闭的弃用警告并未解决这个工单中给出的首要问题：“很容易在不知道的情况下使用已弃用的命名空间。”

这与反射警告不同。您任何时候都可以根据自己的意愿关注速度。但最终可能会突然删除有风险的功能，这会是一个突然的、不愉快的惊喜；警告会有所帮助。

但是 - 假设我写了300行Clojure代码，使用了1000行来自jar的代码。我的代码中是否存在任何弃用问题会被埋没在那些jar的警告洪流中？更糟的是，这个洪流可能会持续数周或数月，直到相应库的作者赶上。鉴于jar可以通过'lein ancient'等工具更迅速地覆盖，我更愿意仅对我的代码限制弃用警告，可能通过namespace前缀，如果从jar中不包括从编译器角度看不方便。