ruby – Smalltalk如何处理monkeypatching？

我是一个 Ruby编码器.对我来说,monkeypatching是在运行时更改外部项目中的类或模块方法.我感兴趣的是,你有什么机制可以保护你免受那些好的功能的滥用.接下来,我遇到的一些场景,monkeypatching已经咬了我.

虽然我根本不了解Smalltalk,但这种语言早在Ruby之前就存在了.我做了一些研究,看看Smalltalk是否以及如何解决其中的一些问题,但在谷歌上找不到多少.所以我在这里,要求Smalltalkers他们是否可以分享他们的智慧.

场景A：错误修复冲突

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

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

场景B：过时的bug修复

Project C发布了项目的固定次要版本.

如果您加载项目A,是否仍会应用补丁,可能会出现破损？我很想知道是否存在某种机制,例如,如果代码是固定的,则不加载补丁.

场景C：冲突的扩展

项目A和B使用项目C的类Foo.两者都为Foo添加了一个实用工具方法,比如#toDate.
toDate版本的A返回一个日期字符串,而一个B是Date对象.

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

关于问题更新

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

解决方法

在Smalltalk中,我们传统上称之为压倒一切.根据您在Smalltalk中使用的版本控制工具,您可以;

>创建最初拥有相关类/方法的包的新版本
>创建一个新的包,它将拥有相关类/方法的覆盖

在VisualWorks和ObjectStudio(我最熟悉的Smalltalk)中,使用了后一种方法.在使用Envy的VA Smalltalk中,采用了前一种方法.我相信Squeak会使用蒙蒂塞洛的后一种方法,但我不完全确定.

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

在客户端应用程序中,当您从venor(或Squeak团队等人)更新到Smalltalk的新版本时,覆盖确实只会影响您.对于服务器应用程序,其中多个应用程序可能驻留在服务器中,您需要更加小心您的决定.

覆盖(或称为猴子补丁)是一种强大的工具,但是你需要注意如何使用它们 – 如果你使用它们,你应该重新检查你是否仍然需要它们.在我的开源新闻聚合器BottomFeeder中,我删除了很多我最初设置的覆盖.