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

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

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'和类似工具更容易地覆盖（更加方便），我更愿意能够将过时警告限制在我的代码上，也许通过命名空间前缀，如果从编译器的角度来看无法方便地使用from-a-jar-or-not。