更易识别已废弃的命名空间和变量

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)是等效的，而不是将绑定到，可能更易读。如果它更可取，我会很高兴提供。

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自身也有一些废用的实例 - 因此也非常希望在补丁中也清理这些。可能需要单独的补丁来完成，取决于是否容易修复。如果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'的方式得到更好的覆盖（更快地），我宁愿将弃用警告仅限制在我的东西上，如果从编译器的角度来看，来自jar或不来自jar的不便，我可能希望可以通过命名空间前缀来限制。