在显式将“clojure.core”符号替换为“use”或“refer”时禁用警告

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 应具有文档和元数据。参见 core.clj 中的 warn-on-reflection 的示例以复制和编辑。

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

在ns_libs.clj的测试描述中可能存在拼写错误：“clojure.core中的符号”而不是“符号是clojure.core”？

如果有人希望从ns形式中的:use语句中获取警告，那么似乎使用补丁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的所有相关实例），它是一个包含不同选项的键值对映射。如果确实希望控制警告，这可能是一个更好的地方。

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"）来表示库函数旨在替换core中的内容。这是一个稍微不同的方法（我认为实施起来也稍微复杂一点），但它也应该有效。

Answer 8

评论者：mikera

由于这个问题，用户报告了一个示例问题

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

Answer 9

评论者：jafingerhut

和以前一样，我无法评论是否有兴趣处理这个工单或这些补丁，但我可以说，2013年9月7日或之前的所有补丁在2014年8月29日Clojure提交了一些更改之后不再干净地应用到最新的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报告）