方法值和语法错误

Question

复制自这个Reddit评论

所以，如果一个歧义的方法是语法错误（实际上是语法？），这意味着当我更新提供新重载的Java库时，我的代码会中断吗？更糟糕的是，如果我的Clojure库在类路径上使用了Java库，然后更新Java库并且现在提供了另一个重载，Clojure库会损坏。这将是个大问题，可能会导致各种更新噩梦。

在Java代码中添加重载是一个非常常见的向后兼容性更改，应该期待不会创建Clojure包装器中产生"语法"错误。

我的个人看法

Clojure的一个优势是代码的弹性，那就是多年以前编写的代码仍然可以工作。这历来适用于为Java库提供典型包装器的库。然而，使用语法错误而不是回退到反射（即使有一个反射警告），意味着这类库（如果它们使用新的方法值语法）将比其他交互代码更加脆弱，限制其在长期代码中的实用性。

我理解使用硬错误的原因（性能、清晰、简单），但我同意这种选择在Clojure的其它方面表现出的惊人的灵活性和愿意支持各种用法的情况下是奇怪的。

在模糊的情况下，回退到反射（以及一个反射警告）会损失或降低什么？

Answer 1

在其他reddit和slack论坛的线程中已经对这个Topic进行了详细讨论，所以我这里就简短谈谈。这里的目标是制作一个高质量的方法值（具体、明确、无反映、适当的提示/强制转换）并且通常我们不想创建具有反映性质的方法值。这个意图与之前的互操作性特性不同，这将引导我们在未来（我预计将会变化）决定使用什么。

Answer 2

我们感谢在这里提出的问题，这给了我们一些新想法，我们会将其纳入下一个版本，谢谢。

Comments

哦，很有趣。感谢你的跟进。

Answer 3

Clojure的一个优势是其代码的恢复力，即几年前编写的东西今天仍然可以工作。

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

我认为人们需要考虑为什么需要更新一个被现有依赖项依赖的Java库？如果你不更新它，它仍然会继续工作。只有当你明确更改你自己的项目中的版本时，它才会出问题，而这种更改总是伴随着风险，你可能会破坏使用它的另一个依赖项。

是的，有时更新Java库的版本有很好的理由——比如解决CVE（安全漏洞通用识别码），或者你可能有两个依赖项，它们都依赖于那个Java库，你想更新其中一个依赖项。但是这种改变总是伴随着风险——甚至Java库的修补版本更新也可能（确实会！）以各种方式造成破坏。

作为一个CI（持续集成）管道，如果出现新的反射警告，就会导致构建失败的，我宁愿有一个保证没有反射，并能立即在本地看到这个错误，而不是在更远的地方才抓到由这个变更引起的问题。

Comments

假设有人说：“实际上……如果你依赖于A和B，它们都依赖于Java库C，你更新A并且它使用了C的新版本，这可能会破坏B！”——如果你不更改依赖项，它将继续工作。

如果你更新了一个更改你的传递依赖项版本的库，你总是冒着破坏的风险。