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}} 平台为默认使用。

第二个补丁更进一步：如果没有提供平台，它会尝试根据旧-sym 的文件扩展名来猜测平台。您可能觉得这是过度复杂化：您可以选择第一个补丁。

Answer 3

评论者：stuart.sierra

感谢你处理这些补丁。我进行了一些更多测试，并发现了更多问题。

猜测文件扩展名会导致不可预测的结果，因为你不知道哪个文件会被移动。例如，在ClojureScript中，拥有同一个命名空间的{{.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的故事是关于探索不同的依赖处理方法，实际上，Glen Mailer总结今年在clojureX上的问题有一个很好的（链接： https://skillsmatter.com/skillscasts/7251-lightning-talks-day-2）。我的想法是创建本地、深度嵌套的依赖项，并可能增强ns宏以能够加载它们——甚至不确定这是否可行。这将消除源内联的需要，更重要的是，我认为这将是一个更加卫生的方法。

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

Answer 5

参考： https://clojure.atlassian.net/browse/TNS-37（由 bencedek.fazekas 提交）