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}} 平台。

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

Answer 3

评论人：stuart.sierra

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

猜测文件扩展名会导致不可预测的结果，因为您不知道哪个文件被移动。在ClojureScript中使用{{:require-macros}}时，同一个命名空间同时拥有{{.clj}}和{{.cljs}}版本的情况并不少见。

遗憾的是，即使指定了“平台”参数，问题也未能完全解决，因为在{{.clj}}和{{.cljs}}文件的同时，您也可能拥有{{.cljc}}文件。这不是很常见，但在《Reader Conditionals》的设计（链接： http://dev.clojure.org/display/design/Reader Conditionals）中明确允许：）例如，一个库可能有一个平台无关的.cljc文件，并使用特定于平台文件的覆写。在这种情况下，即使指定了“平台”参数，您也无法控制哪个文件被移动。

因此，我认为像“移动命名空间”这样的操作只有移动定义该命名空间的所有文件，并保留它们的文件扩展名，才有意义。这看起来也是用户期望的。

因此，应该使用new/old符号，找到所有匹配的文件（任何扩展名），在保留扩展名的同时移动/重命名它们，然后对所有.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报告）