在显式用 "use" 或 "refer" 替换 clojure.core 符号时禁用警告

Question

问题：提供 DSL（如 core.matrix）的库通常替换或扩展核心中的函数（如 "+", "==", "zero?"），因为这希望使用最佳/最惯用的名称。

目前使用 "use" 导入此类库会导致不希望的警告，例如 "WARNING: + 已经引用：#'clojure.core/+ 在命名空间：test.blank，被替换为：#'clojure.core.matrix/+"。

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

提议的解决方案是引入一个新变量 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中的测试描述中可能有一个错别字：“在clojure.core中的符号”可能应该改为“符号在clojure.core中”？

如果有人希望在ns形式中使用：use语句时收到警告，使用patch clj-1257.diff修补文件在ns形式之前设置（set! warn-on-replace true）似乎是唯一的方法。但这与当前版本的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变体），它是一个映射，其中每个键/值对代表一个不同的选项。如果警告-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

看起来补丁从最后一次有关当前补丁的讨论更新后从未被更新，因此从未被筛选。我认为我会选择走**warn-on-reflection**这条路，而不是编译器选项。

Answer 14

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