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

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))
;;=> 弃用警告：从命名空间 `foo` 加载弃用命名空间 `bar`


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

我曾希望将源文件、行和列信息快速方便地添加到弃用警告消息中。这并不像添加到格式()调用中那样简单，因为 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）。它作为一个map在编译器中实现。它比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 发布

对于任何想要查看此功能但是检查这个ticket的人，Eastwood lint工具报告了对已弃用的Clojure函数调用以及已弃用的Java方法的调用。[https://github.com/jonase/eastwood](https://github.com/jonase/eastwood)

Answer 10

评论者：alexmiller

我考虑将其用于Clojure 1.9，但我需要帮助将准备就绪。以下是我对当前状态的一些评论：- Ticket需要更多关于当前进近的详细信息

• 我宁愿用 }替换，因为它会重复你用来标记已弃用变量的关键字
• 警告消息没有指明位置，真的很糟 - 应该类似于反射消息
• 需要测试 - 看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包中提取（是否）不太方便。