方法值和语法错误

Question

来自这个 Reddit 评论

如果一个含义不清的方法是语法错误（实际上是语法错误？），那么是否意味着，当更新一个提供新重载的 Java 库时，我的代码就会中断？更糟糕的是，如果我有一个位于类路径上的 Clojure 库使用了 Java 库，然后我更新了这个 Java 库，而它现在提供了另一个重载，Clojure 库就会崩溃。这将非常糟糕，并可能导致各种更新地狱。

添加重载是 Java 代码中非常常见的一种向后兼容的更改，应该预料到这种情况。请不要让它在 Clojure 包装器中创建“语法”错误。

我自己的话

Clojure 的一项强项是代码的弹性，一些多年前的代码现在仍然可以使用。这历来适用于提供 Java 库约定性包装器的库。然而，使用语法错误而不是回退到反射意味着，如果这些库（如果它们使用新的方法值语法）将比其他交互代码更加脆弱，限制了它在长期代码中的实用性。

我理解使用硬错误的理由（性能、清晰直观、简单），但我同意，鉴于 Clojure 通常的卓越灵活性和支持各种使用的意愿，这是一个奇怪的选择。

在含义不清的情况下，回退到反射（以及一个反射警告）会丢失或降级什么？

Answer 1

在Reddit和Slack上的其他线程中对此进行了详细的讨论，因此我会简要说明，但这里的意图是制作高质量的方法值（具体、明确、无反射、适当的提示/强制类型转换），而创建反射方法值通常是我们不想做的事情。这种意图与之前的功能不同，并将驱动有关未来（我预计将进化）使用什么的选择。

Answer 2

我们感谢在此提出的问题，它为我们提供了一些新想法，并将纳入下一个迭代，谢谢。

Comments

哇，很有趣。感谢跟进。

Answer 3

Clojure的一个优势是代码的弹性，即几年前编写的代码至今仍然可以工作。

如果你不更改依赖关系，它将继续工作。

我认为人们需要考虑为什么要更新一个当前依赖的Java库？如果你让它保持原样，它将继续工作。只有当你明确地更改你自己的项目中版本时，它才会出现问题；这种改变总是有可能破坏一个也使用该库的依赖。

是的，有时有很好的理由要覆盖Java库的版本——比如解决CVE，或者你有两个依赖都依赖于这个Java库，你想更新其中一个依赖。但这类变更总是存在风险——即使是Java库的补丁发行版更新也可能（并且确实）以各种方式引入破坏。

作为一名CI管道配置者，如果出现新的反射警告会导致构建失败，我更愿意保证没有反射，并立即在本地看到错误，而不是等待更线下的变更引入的问题被发现。

Comments

如果有人提出“实际上...如果你依赖于A和B，它们都依赖于Java库C，你更新了A并使用C的新版本，它可能会破坏B！”——如果你不改变依赖关系，它将继续工作。

如果你更新一个会改变你的转移依赖版本号的库，你总是有破坏风险。