tools.namespace 不识别由 data_readers.cljc 引申的 ns 依赖

Question

我在代码库中发现了关于一些标记字面量似乎违反最小惊喜原则的有趣问题

我们创建了一些纯数据描述的过程，包括从在 data_readers.cljc 中声明的自定义标记字面量读取器中创建的一些 defrecord 对象，并让这些 defrecord 对象参与一个协议。这一切都工作得很好，直到我遇到了这个问题

有人将这些标记字面量中的一个放入了一个 def（一开始看起来似乎是一件合理的事情）

(def foo #ctx/event-path [:blah])

这没问题...直到调用了 c.t.n.r/refresh，之后一切都破裂了

结果发现，defrecord 对象 foo 的类已经过时（可能是由于在 data_readers.cljc 中声明的标记字面量解析程序诱导的命名空间依赖不被 tools.namespace 识别，因此命名空间按顺序重新编译）

tools.namespace 是否应该能够识别 data_readers.cljc 诱导的依赖？或者这是它过分做的一个步骤？

Answer 1

在这里，我认为一个重要的考虑因素是，拥有一个data_readers.cljc文件并不会自动加载或要求读者函数的命名空间。您的程序在读取分配给相应读者函数的标记文本之前，仍然负责要求包含读者函数的命名空间。这对于源代码中的标记文本来说往往是件令人头疼的事，也许应该对其进行修改，但现在就是这样运作的。

因此，包含def隐含地依赖于读者命名空间以便能够读取，正确的事情是在该命名空间的ns定义中明确这个依赖关系。如果有那样做，就没有“由data_readers.cljc引起的依赖”，只有已经在命名空间定义中明确表达的依赖，这样您就不会遇到这个问题。

因此，我认为这并不是tools.namespace（考虑到Clojure的当前实现）需要的特性。

Comments

嗯——这是一个关键的点@alexmiller——这意味着我对`c.t.n.r/refresh`之后事物为什么会失败的理解是错误的（但prod环境中从未发生过这种情况）

回到画板

Answer 2

我对这个问题的最初反应是：“嗯，c.t.n.r/refresh可以破坏所有 sorts of things，我看到很多初学者在使用reload/refresh工作流程时遇到麻烦...”，这就是为什么我总是跳进每个出现reload/refresh的对话，并说“别这么做！”

在我看来，这与其说是对一个问题的一种方案，不如说是对由于原始REPL工作流程不理想而引起的问题的一种糟糕的解决方案。不要仅仅在上面贴上创可贴，而应该鼓励更好的REPL工作流程。

是的，我知道Clojure的某些部分确实可以生成Java类，在REPL中可能会导致问题——但c.t.n.r/refresh根本不能解决所有这些情况（我认为它也使人们停止思考这些问题）。

我确实希望核心团队就REPL友好的处理记录（以及其他Clojure/Java互操作领域的某些建议）给出一些指导。我看到一些建议认为使用生成的函数而不仅仅是引用记录类型会有所帮助，但我认为关于如何组织需要更好指导的记录的协议扩展仍然存在问题？

Comments

在https://github.com/aredington/clojure-repl-sufficient-p有一个有趣的仓库，它突出了当前REPL实现的一些缺点，如果有人有兴趣添加这个特案，可以考虑包括在内。我特别喜欢这个仓库在期待某些活动方面的组织方式。

---

如果这个仓库真的能够实际_解释_具体的问题是什么以及如何减轻这些问题，将会是一个非常有用的仓库。源代码文件和那个测试文件在其意图上都非常晦涩难懂。

只有在comp/wrapper的源代码文件中，它才试图展示一个友好的REPL等效实现。

---

Sean，针对我的情况，我发现了一种构建记录的方式，这样记录的协议实现就可以在协议类因依赖顺序重新加载而发生变化时生存下来 - 通过使用`:extend-via-metadata`。它不是很优雅 - 使用记录类型来分发print-method以将记录序列化为标记字面量，并使用元数据来实现协议，但它有效。

(不幸的是，它只对clj有效，在cljs上遇到了难以理解的编译错误，所以我现在放弃了为带有完整序列化往返的完全定制的标记字面量整个想法)

Sean，我想进一步了解你描述的“不尽如人意”和“更好”的REPL工作流程 - 你能提供链接吗？

---

我对这个非答案有点失望。一个更积极的态度会是“确实，这个库里有缺陷，可以修复”。

如果修复了tools.namespace中的bug，我们就不会讨论它“会引起各种问题”了。

不断地劝阻开发lib相当于自我实现的预言——在某个时刻，由于FUD的影响，将不再有很多人愿意为tools.namespace开发。这导致缺陷的持续。

希望有人能承担tools.namespace的开发。对于我现在使用的分叉版本，我非常满意。我目前没有时间改进官方的t.n。

---

这有点夸张，vemv——我没有劝阻tools.namespace，我是在劝阻特定的更新（我认为缺陷在于工作流程，而不是库）。

---

无论是否夸张，我仍然对不断反对某种特定方法（可能有一个华丽的名字，但无非只是'自动化'）感到困惑。在我们的社区中通常看不到这一点，正如在https://clojure.org/community/etiquette 中所反映的那样。

---

请让我们把讨论集中在手头的问题上。