ruby - Smalltalk 如何处理 monkeypatching？

Question

我是一名 Ruby 程序员。对我来说，monkeypatching 是在运行时更改外部项目中的类或模块方法。我感兴趣的是，您有什么机制可以保护您免受某些滥用该优良特性的影响。以下是我遇到的一些场景，其中 monkeypatching 让我很头疼。

虽然我根本不知道 Smalltalk，但这种语言早在 Ruby 出现之前就已经存在了。我做了一些研究，看看 Smalltalk 是否以及如何解决其中的一些问题，但在 Google 上没有找到太多。所以我在这里，询问 Smalltalkers 是否可以分享他们的智慧。

场景 A:bug 修复冲突

项目 A 和 B 依赖于项目 C。项目 C 有一个错误。项目 A 和 B 版本包含对项目 C 的修复。

如果您的代码使用项目 A 和 B，您怎么知道补丁不会冲突？

场景 B:过时的错误修复

项目 C 发布了他们项目的固定次要版本。

如果您加载项目 A，补丁是否仍会应用，但可能会损坏？我很想知道是否有某种机制，例如，如果代码已修复，则不加载补丁。

场景 C:扩展冲突

项目 A 和 B 使用项目 C 的类 Foo。两者都向 Foo 添加实用方法，例如 #toDate。A 的 toDate 版本返回日期字符串，B 的版本返回日期对象。

如果您加载两个项目(使用 C dep)，是否有一种机制可以警告/防止冲突？或者您是否必须等到运行时因方法中的错误预期而引发错误？

关于问题更新

阅读答案后，我意识到我的问题过于宽泛和模糊。所以这是它的重写版本。

Answer 1

在 Smalltalk 中，我们传统上将其称为覆盖。根据您与 Smalltalk 一起使用的版本控制工具，您可以；

• 创建最初拥有相关类/方法的包的新版本
• 创建一个新包，该包将拥有所讨论的类/方法的覆盖

在 VisualWorks 和 ObjectStudio(我最熟悉的 Smalltalk)中，使用的是后一种方法。在使用 Envy 的 VA Smalltalk 中，采用了前一种方法。我相信 Squeak 会使用 Monticello 遵循后一种方法，但我不完全确定。

在大多数 Smalltalk 实现中，很容易看到被覆盖代码的原始版本和当前安装的覆盖。

在客户端应用程序中，覆盖实际上只会在您从供应商(或 Squeak 团队等)更新到新版本的 Smalltalk 时影响您。对于服务器应用程序，其中多个应用程序可能驻留在服务器中，您需要更加谨慎地决定做什么。

覆盖(或猴子补丁，如您所说)是一个强大的工具，但您需要注意如何使用它们 - 如果您确实使用了它们，您应该重新检查是否仍然需要它们定期。在我的开源新闻聚合器中，BottomFeeder ，我已经删除了很多我最初设置的覆盖。