通过 Boost 评审流程改进库：以 OpenMethod 为例

自2013年以来，我一直在从事实现开放多方法的库的开发
在现代C++中。在我发布第一个库 - YOMM11 - 后，我在 Boost
邮件列表中询问是否有人有兴趣将 YOMM11 纳入 Boost。当时
兴趣不大。

在我发布了改进了很多的 YOMM2 后，我又尝试了一次，但兴趣
仍然微弱。或者，也许我没有解释清楚它是什么。

无论如何，我继续将 YOMM2 作为独立项目进行改进，并且
回顾来看，我认为当时这样做是最好的。YOMM2 有很多
用户，他们积极给我发送 PR，而且在 bug 方面也没有
带来太多麻烦。至于其内部，可以说，它们看起来像是一个
正在进行的实验。

然而，多年来，我清理了实现。在 reddit 上的讨论之后，我
提高了在功能、性能、占用空间等方面的标准。
例如，我增加了对自定义 RTTI 的支持。

我偶尔会在会议上谈论 YOMM2。2024年，我参加了由 J.D. Garcia 教授在马德里卡洛斯三世大学组织的“使用 std::cpp”会议。
由 J.D. Garcia 教授在马德里卡洛斯三世大学组织的“使用 std::cpp”会议。
Joaquín M López Muñoz 正在做关于完美哈希的讲座，这是一种
YOMM2 中使用的技术。Garcia 教授将我介绍给了 Joaquín，我告诉
他们我的库的故事，以及我与 Boost
社区的互动。

原来 Joaquín 本人也是 Boost 的作者。他建议我再次尝试，并
提出为我担保。这将确保我获得正式评审。我说我会
考虑一下。

我决定继续前进，原因有几个。我承认虚荣是其中之一！
但我也“更好”的动机。我觉得我没有取得多少
成功让 C++ 社区了解我的工作。我猜想将其纳入 Boost
会有所帮助。最重要的原因……嗯，我今年 62 岁，有一些
健康问题。我可能还会活一段时间，但以防万一，我
想让我的库有可能尽可能长久地存活下来。而
Boost 在保存 C++ 库方面做得非常好，即使作者和
维护者来来往往。

Dmitry Arkhipov，C++ Alliance 的成员（与 Joaquín 一样），提议管理
评审。结果他过去的一个项目需要开放多方法。
如果他早知道 YOMM2 的存在，他就会使用它了。

我又进行了一轮清理，在此期间我将一些内部组件（如 virtual_traits）移到了公共接口，并在此过程中对其进行了改进。

如果该库被接受，它将以 Boost.OpenMethod 的名称出现。

评审开始了。说实话，我一直在鼓起勇气，期待
冷漠。恰恰相反，几天后，评论，然后正式评审
开始涌入（正式评审必须遵循格式，特别是必须
明确投票“接受”、“有条件接受”或“拒绝”）。

所有的评论、评审以及它们引发的辩论都非常
有趣。它们进一步打磨了我的设计。例如，我重新设计了策略
系统（一组重要的自定义点，支持诸如
自定义 RTTI 等功能）。

只有一位评审者投票拒绝。尽管如此，与他的谈话
同样令人振奋。和其他人一样，而且比其他人更强烈，他
批评了一项我最终将其设为可选的功能。

我将尝试在不详细介绍的情况下进行描述。我的库是
深受 Stroustrup 等人撰写的论文的启发，他们在尝试
将开放多方法引入 C++ 标准。在他们关于
该主题的最后一篇论文（搜索 N2216）中，他们建议了一种处理歧义
的方法，基本上使它们不再是错误。我不喜欢这个想法，YOMM2 从未
实现它，但我（羞愧地）将其应用于 OpenMethod。几乎所有人都
不喜欢它！避免了错误。

一些评审者对实现细节的底层有着惊人的掌握。
我很高兴 Steven Watanabe 提交了两段代码，它们将 OpenMethod 与 Boost.Any 和 Boost.TypeErasure 结合。
OpenMethod 与 Boost.Any 和 Boost.TypeErasure 接口。

评审结束时，OpenMethod 被有条件接受——一些
我完全同意的修改。但即使它被拒绝了，
也已经不虚此行了。OpenMethod 比
YOMM2 好得多。而且它被接受了！

OpenMethod 将在 Boost 1.90.0 版本中加入大家庭。