更方便地识别过时名称空间/变量

Question

来自邮件列表 http://groups.google.com/group/clojure/msg/c41d909bd58e4534。在不清楚自己的行为时会轻松地使用过时的名称空间或变量。文档警告信息很小，并且没有编译器警告。

**建议：**

**添加新的 {{\*warn-on-deprecated*}} 动态变量，默认值为 false
**当日志载入具有 böyle {{:deprecated true}}} 标识的名称空间时，向标准错误输出警告。
**当日志分析具有メント {{:deprecated true}}} 变量时，向标准错误输出警告。
**当日志展开具有 {{:deprecated true}}} 宏时，向标准错误输出警告。
**新的系统属性 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 发表

我不介意向标准错误输出警告

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添加得更晚些，可能是添加更多此类选项的首选方法，以避免在多处pushThread Bindings调用中继续添加更多参数。

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感到兴趣，但我需要一些帮助将其准备就绪。我对当前状态有一些看法：- 票需要关于当前方法的更多详细信息

• 我更喜欢

  {

  而不是

  }}，因为它回响了您用来标记弃用变量的关键字

• 警告信息没有告诉您位置，这令人不快 - 应该与反射信息相似
• 需要测试 - 请参阅 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包的代码。我的代码中的任何 deprecated 问题会被那些jar包的警告的巨浪淹没吗？更糟糕的是，这个巨浪可能会持续数周甚至数月，直到各个库的作者追赶上。鉴于这些jar包（更加方便地）被'lein ancient'和类似的命令覆盖，我宁愿限制 deprecated 警告仅限于我的代码，也许可以通过命名空间前缀来实现，如果从jar包中导入不便从编译器的角度来看。