当显式使用"use"或"refer"替换clojure.core符号时，抑制警告

Question

问题：提供领域特定语言(DSL)的库(如 core.matrix)经常替换或扩展核心中的函数(如 "+", "==", "zero?" ), 因为使用最合适的或最符合语言的名称是首选的。

目前，用 "use" 导入这样的库会导致不想要的警告，如 "WARNING: + 已在命名空间: test.blank 中引用: #'clojure.core/+, 正被替换为: #'clojure.core.matrix/+"。

避免这些警告需要额外的用户努力和样板代码，这对用户来说很令人沮丧，因为他们已经明确要求将整个库导入当前命名空间(i.e. via "use" 或 ":refer :all")。

建议的解决方案是引入一个新的变量 warn-on-replace，类似于 warn-on-reflection，它允许控制此警告。

Answer 1

评论者：mikera

附上了基本补丁和测试。

Answer 2

评论者：jafingerhut

我不知道这个想法是否会得到评估，但如果有，我有一些关于提议补丁的评论。

新的符号 warn-on-replace 应该有文档和元数据。请参阅 core.clj 中 warn-on-reflection 的 add-doc-and-meta 以获取复制的示例并编辑。

在 Namespace.java 中，在发布警告之前检查 WARN_ON_REFLECTION，而不是 WARN_ON_REPLACE。

在 ns_libs.clj 中的测试描述中可能有打印错误：也许应该是 "clojure.core 中的符号" 而不是 "symbol is clojure.core"？

如果有人希望在 ns 表单中使用 :use 语句时收到警告，那么使用 patch clj-1257.diff 实现这一点的方法似乎只有一个，就是在文件中 ns 表单之前执行 (set! warn-on-replace true)。这可能与当前版本的 tools.namespace 不兼容，因为它假设如果存在 ns 表单，则它将是文件中的第一个表单。尽管人们可以论证 tools.namespace 不应做出这种假设，但现阶段它是这样做的。

可能应该有一个命令行选项 clojure.compile.warn-on-replace，就像 clojure.compile.warn-on-reflection 一样？（在 Compile.java 中搜索 warn-on-replace）？

Answer 3

评论者：mikera

感谢Andy的反馈！我将很快发布一个更新补丁。

我突然想到，我们可能应该在 Clojure 中实现一种更通用的警告方法。为每个警告添加新变量和命令行选项似乎不是一种良好的长期策略。但我想这超出了这个补丁的范围。:-)

Answer 4

评论者：jafingerhut

实际上，有一个叫做 compiler-options 的东西（搜索 compiler-options、COMPILER_OPTIONS 和 compiler_options 的所有相关出现），它是一个map，其中每个键/值对是不同的选项。如果确实希望为 warn-on-replace，这可能更可取。

Answer 5

评论者：mikera

已附加更新补丁。

如果这是控制警告的首选策略，那么 compiler-options 可能是一个更好的地方。但在做出这个更改之前，我会等待更多的反馈/确认。

Answer 6

评论者：alexmiller

(:refer-clojure :exclude (link: + = zero?)) 是否是一个有效的解决方案？或者你真的担心库的消费者吗？

Answer 7

评论者：mikera

我主要关注库的消费者。

尽管(:refer-clojure :exclude (link: + = zero?))作为临时解决方案是可能的，但它对用户来说非常不便。我们真的应该在Clojure自身中解决这个问题。用户已经在ns表单上遇到了足够的麻烦，无需再增加他们的烦恼。

作为另一种解决方案：我个人不会介意库作者在一些符号中添加一些元数据（例如："^:replace-symbol"），以表示库函数 intends to replace something in core。这是一种略有不同的方法（我认为实施起来比较棘手），但应该也有效。

Answer 8

评论者：mikera

用户报告的由于这个问题而产生的问题示例。

https://github.com/mikera/vectorz-clj/issues/23

Answer 9

评论者：jafingerhut

与之前一样，我无法评论是否有人对这个票据或这些补丁感兴趣，但可以说，在2014年8月29日对Clojure做出某些提交之后，所有2013年9月7日及之前日期的补丁都无法干净地应用到最新的master分支上。在那之前，它们是可以干净地应用的。

我还没有检查更新这个补丁可能会多么容易或困难。

Answer 10

评论者：mikera

我很愿意更新补丁，只需反馈对哪个方法/解决方案更喜欢即可。

我真的希望能在1.7版本中看到这一点！

Answer 11

评论者：alexmiller

将相关信息链接到CLJ-1746。

Answer 12

评论由：jmromrell

这到底有什么结果呢？我正在尝试解决来自monger等库的类似警告。

Answer 13

评论者：alexmiller

看起来补丁从未根据上一次关于当前补丁的讨论进行更新，因此它尚未被审查。我认为我会走**warn-on-reflection**的路，而不是编译器选项。

Answer 14

参考：[CLJ-1257](https://clojure.atlassian.net/browse/CLJ-1257)（由mikera报告）