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

Question

来自邮件列表 http://groups.google.com/group/clojure/msg/c41d909bd58e4534。在不知情的情况下使用已弃用的命名空间或变量很容易。文档警告很小，且没有编译器警告。

*建议：*

* 添加新的 {{\*warn-on-deprecated*}} 动态变量，默认为 false
* 当加载具有{{{: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后添加的，可能是添加更多此类选项的首选方法，以避免需要在多个地方的pushThreadBindings调用中继续添加更多参数。

Answer 7

由 gshayban 发布的评论

谢谢，Andy。

作为最后ns补丁的替代方案，调用（print-method msg err）与绑定out到err等价，可能更易读。如果 prefer，我将很乐意发送。

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的此特性感兴趣，但我需要一些帮助使其准备就绪。我对当前状态的一些评论：- 票需要更多关于当前方法的细节

• 我更喜欢 usado 因为其 echoes 你用来标记弃用变量的关键字
• 警告消息没有提供位置信息，这很烦人 - 应与反射消息类似
• 需要测试 - 参考 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包的代码。我的代码中的任何过时问题会不会被那些jar包的警告巨浪淹没？更糟的是，这个巨浪可能持续数周或数月，直到各个库的作者跟上。既然jar包（更方便地）被'lein ancient'等工具覆盖，我宁愿能将过时警告限制在我的代码中，也许可以通过命名空间前缀来实现，如果从编译器的角度来看从jar包中获取.arc不方便。