使用过时命名空间/变量更易识别

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)

;; overloaded 过时的变量（在编译时）
(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))
;;=> 过时警告：加载已过时的命名空间 `foo` 来自命名空间 `bar`


**补丁：** 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

还有一个独立的命令行开关称为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代码检查工具报告对已弃用的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的100万行代码。我自己的代码中的任何弃用问题会不会被那些jar的警告淹没？更糟糕的是，这种海啸可能需要几周或几个月，直到库的相应作者赶上。由于jar被'lein ancient'之类的工具处理得更快，我宁愿限制弃用警告只针对我的代码，也许可以通过命名空间前缀来实现，如果从编译器视角看，从jar中不是很不方便的话。