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

好主意 - 很高兴看到人们如何在实际开发中使用 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}} 平台为默认使用。

第二个补丁进一步扩展了这一点：如果没有提供平台，它会根据旧符号的文件扩展名尝试猜测它。你可以将其视为过度复杂，如果这样，你可以选择第一个补丁。

Answer 3

评论者：stuart.sierra

感谢你们对补丁的工作。我进行了更多测试，并发现了更多复杂问题。

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

不幸的是，即使指定“平台”参数也不能完全解决问题，因为你可以同时拥有{{.cljc}}文件、{{.clj}}和{{.cljs}}文件。这种情况可能不太常见，但在设计读取条件（http://dev.clojure.org/display/design/Reader Conditionals）的文本中明确允许：设计读取条件）。例如，一个库可能有一个平台无关的{{.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 提交）