更易于使用已弃用的命名空间/变量

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 已弃用

;; 使用已弃用的宏（在宏展开时）
(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开发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方法的调用。noopener
链接：[https://github.com/jonase/eastwood](https://github.com/jonase/eastwood)

Answer 10

评论者：alexmiller

我打算考虑在Clojure 1.9中使用这个功能，但我需要一些帮助来使其准备就绪。我对当前状态的一些评论：-工单需要更多当前方法的详细信息

• 我更喜欢使用 因为它回显你用来标记已弃用的vars的关键字
• 警告信息没有提供位置信息，这很让人头疼 - 应该与反射信息类似
• 需要测试 - 请参阅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代码，使用了100万行来自jar的代码。我自己的代码中的任何弃用问题会被那些jar的成堆警告所淹没吗？更糟糕的是，这种浪潮可能会持续几周或几个月，直到各库的相应作者赶上。由于jar包可以通过'lein ancient'和类似的工具（更快地）进行处理，我希望能够将弃用警告限制在我的代码范围内，也许可以通过命名空间前缀，如果从编译器的角度看来从jar包中不方便。