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

Question

看起来 c.t.n.move 没有获得任何读取条件语句的青睐。我使用这个命名空间为 (链接：[https://github.com/benedekfazekas/mranderson](https://github.com/benedekfazekas/mranderson) 文本：mranderson) 提供动力：一个源内联工具，由 cider-nrepl 和 refactor-nrepl 使用，以便避免与用户正在工作的代码/项目冲突。最近我们开始向 refactor-nrepl 添加依赖关系（好吧，tools.namespace 本身），这可能需要 .cljc 文件。这些源文件开始失败。

Answer 1

评论由：stuart.sierra 创建

好主意——很高兴看到人们如何在其他开发工具中使用 tools.namespace。

能否进一步扩展以将 '平台' 作为参数，就像 {{c.t.n.find}} 或 {{c.t.n.dir}} 一样？

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

Answer 2

评论由：benedek.fazekas 创建

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

第二个补丁更进一步：如果没有提供平台，它将尝试根据旧符号的文件扩展名猜测它。您可能认为这是过度复杂，那么请自由选择第一个补丁。

Answer 3

评论由：stuart.sierra 创建

感谢您对这些补丁的工作。我进行了更多的测试，并发现了更多的问题。

猜测文件扩展名会导致不可预测的结果，因为你不知道哪个文件会被移动。比如，在ClojureScript中，同时有{{.clj}}和{{.cljs}}版本的同一命名空间是很常见的。

遗憾的是，即使指定了“平台”参数，也无法完全解决问题，因为您可能同时拥有{{.cljc}}、{{.clj}}和{{.cljs}}文件。这虽然不常见，但在http://dev.clojure.org/display/design/Reader+Conditionals文本（读者条件的设计）中有明确说明：允许这种情况。例如，一个库可能有一个平台的.bclc文件，并可以用平台特定的文件覆盖它。在这种情况下，即使指定了“平台”参数，您也无法控制哪个文件会被移动。

因此，我认为像“移动命名空间”这样的操作唯一合理的方式是移动定义该命名空间的所有文件，保留它们的文件扩展名。这在用户层面上看起来也是人们想要的。

因此，{{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的故事是探索依赖关系处理的不同方式，例如，Glen Mailer在clojureX今年的一个很好的（链接：https://skillsmatter.com/skillscasts/7251-lightning-talks-day-2文本：闪电演讲）中总结了这个问题。我的想法是创建本地、深层嵌套的依赖关系，并可能改进ns宏以能够加载它们——甚至不确定这是否可行。这将消除源内联的需求，而且更重要的是，我认为它将是一个更洁净的方法。

希望这有意义。对于显然超出了这个工单范围的大脑风暴，我感到抱歉。

Answer 5

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