c.t.n.move: 不支持移动 .cljc 文件

Question

看起来 c.t.n.move 没有得到任何读取条件的支持。我使用这个命名空间为 (链接：https://github.com/benedekfazekas/mranderson 文本：mranderson) 提供动力：这是一个用于避免与用户正在工作的代码/项目冲突的源内联工具，被 cider-nrepl 和 refactor-nrepl 使用。最近我们开始向 refactor-nrepl 添加依赖（好吧，实际上就是 tools.namespace）可能会使用 .cljc 文件。源内联对于这些源文件开始失败。

Answer 1

评论者：stuart.sierra

好主意 - 高兴看到人们在其他 dev cools 中实际使用 tools.namespace。

这个功能可以进一步扩展，将 'platform' 作为参数吗？就像 {{c.t.n.find}} 或 {{c.t.n.dir}} 一样？

（我故意排除了 {{c.t.n.move}} 以限制 0.3.0 版本中更改的范围，但您的补丁表明这可能并不如此困难。）

Answer 2

评论者：benedek.fazekas

第一个补丁做了您要求的事情，我希望如此。保留了 {{move-ns}} 的原始签名以实现向后兼容：默认使用 {{clj}} 平台。

第二个补丁更进一步：如果没有提供平台，它会尝试根据 old-sym 文件扩展名猜测平台。您可能认为这是过度复杂：请随意选择第一个补丁。

Answer 3

评论者：stuart.sierra

感谢您为这些补丁进行工作。我进行了一些额外的测试，并发现了一些更多的复杂性。

推测文件扩展名会导致不可预测的结果，因为你不知道哪一个文件会被移动。例如，由于在ClojureScript中有{{:require-macros}}，同一个命名空间同时存在{{.clj}}和{{.cljs}}版本并不罕见。

不幸的是，即使指定了一个"平台"参数，也不能完全解决问题，因为你可以同时拥有{{.cljc}}文件、{{.clj}}和{{.cljs}}文件。这种情况可能不多见，但在《链接：(http://dev.clojure.org/display/design/Reader+Conditionals) reader条件的设计》中明文允许：例如，一个库可能有一个平台无关的CLJC文件，并用平台特定的文件覆盖它。在这种情况下，即使指定了"平台"参数，你也无法控制哪个文件会被移动。

因此，我认为操作如"移动命名空间"的唯一合理方式是移动定义该命名空间的所有文件，保留它们的文件扩展名。我认为这符合用户的角度。

因此，{{move-ns}}应接受新旧符号，找到所有匹配的文件，包括任何扩展名，在保留扩展名的同时移动或重命名它们，然后对所有的{{.clj}}、{{.cljs}}和{{.cljc}}文件应用文本转换。

如果我们正在寻找文件，我们也可以消除指定源路径的需要，这也就与TNS-39有关。

Answer 4

评论者：benedek.fazekas

我没有放弃这个工单或补丁，但它似乎与支持多平台项目的更大问题有关，因此也与TNS-38有关。

我还在考虑更广泛的背景：《move-ns》不仅用于mranderson的源代码内联，还有refactor-nrepl功能(链接：https://github.com/clojure-emacs/clj-refactor.el/wiki/cljr-rename-file-or-dir)基本上是用TNS的其它部分重新实现了这一功能。

mranderson的故事对我来说是关于探索处理依赖关系的不同方法，今年在clojureX上有Glen Mailer对问题的概述(链接：https://skillsmatter.com/skillscasts/7251-lightning-talks-day-2)。我的想法是创建本地、深层嵌套的依赖关系，也许可以增强ns宏以能够加载它们——甚至不确定这是否可行。这将消除源代码内联的需要，并且更重要的是，我认为这是一个更卫生的方法。

希望这说得通。抱歉这显然超出了这个工单的范围。

Answer 5

参考资料： https://clojure.atlassian.net/browse/TNS-37 （由benedek.fazekas报告）