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

Question

问题：提供 DSL（例如 core.matrix）的库通常会替换或扩展核心函数（例如 "+", "==", "zero?"），因为使用最佳/最约定的名称更可取。

目前，使用 "use" 导入此类库将导致不希望的警告，例如 "WARNING: + already refers to: #'clojure.core/+ in namespace: test.blank, being replaced by: #'clojure.core.matrix/+"。

避免这些警告需要额外的用户工作量和对代码模板而言，对于已经明确请求将其完整库导入当前命名空间（即通过 "use" 或 ":refer :all"）的用户来说是很令人沮丧的。

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

Answer 1

评论者：mikera

附加了一个基本的补丁和测试。

Answer 2

评论者：jafingerhut

我不知道这个想法是否会经过审查，但是如果它被审查，我对建议的补丁有一些评论。

新的符号 warn-on-replace 应该在其上有 doc 和 metadata。请参考 core.clj 中 warn-on-reflection 的 add-doc-and-meta 来复制和编辑的示例。

在 Namespace.java 中检查 WARN_ON_REFLECTION 之后再发出警告，而不是 WARN_ON_REPLACE。

ns_libs.clj 文件中的测试描述可能存在错别字：可能是 "symbol in clojure.core" 而不是 "symbol is clojure.core"。？

如果有人希望在 ns 表达形式中使用 :use 语句时得到警告，那么似乎唯一的方法是先在 ns 表达式之前在文件中执行 (set! warn-on-replace true)。但这与当前 tools.namespace 版本不太兼容，因为 tools.namespace 假设如果存在 ns 表达式，它将是文件中的第一个表达式。有人可能会说 tools.namespace 不应该有这样的假设，但现在它确实这样做了。

也许应该有一个类似于 clojure.compile.warn-on-reflection (在 Compile.java 中查找 warn-on-replace) 的命令行选项 clojure.compile.warn-on-replace？

Answer 3

评论者：mikera

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

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

Answer 4

评论者：jafingerhut

实际上，有一个叫做 compiler-options 的东西（查找变体 compiler-options, COMPILER_OPTIONS 和 compiler_options，以找到所有相关实例），它是一个映射，其中的每个键/值对都是不同的选项。如果这是首选的警告控制策略，这可能更适合 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"）来表示库函数旨在替换核心中的某些内容。这是一个略有不同的方法（我认为实施起来可能也有些棘手），但这也应该可行。

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

看起来补丁从未在当前补丁的最后讨论中得到更新，所以它从未被审查。我认为我会选择Blocked by '**warn-on-reflection**'方法而不是编译器选项。

Answer 14

参考资料：https://clojure.atlassian.net/browse/CLJ-1257（由mikera报告）