问题标签 [multidispatch]

考虑这个程序，我在参数列表中构造了一个数组。虽然有一个接受数组的签名，但这调用了接受列表的签名：

我从一个意外的例程中得到输出：

如果我取消注释该其他签名，则该签名称为：

为什么不调用( Array @array )版本？调度员如何做出决定（以及记录在哪里）？

我正在尝试基于这篇文章http://www.artima.com/weblogs/viewpost.jsp?thread=101605实现一种多方法方法。这种方法有两个不同之处：

• 我只需要看多方法的第一个参数，所以不需要形成 arg 类的元组
• 多方法将存在于类中，它们不会是常规函数。

但是，我把我的类弄混了一点，self在调度类方法的调用时调用会丢失。

这是我的代码：

因此，当我在一个类上调用该send_messages方法时，我会收到 in 中的参数，而不是变量中的参数。这里：Senderselfmessage

输出：

如何不丢失self消息内容并将其发送到message变量？

我正在玩这个小东西，其中一组可以通过翻转测试来充当它的补充。为了完成这项工作，我创建了成员操作符的特殊版本。

根据我infix:<∉&gt;对另一个的定义，更一般的定义似乎已经消失了。没有其他候选人：

我需要做些什么来保留具有不同签名的先前定义？

我有一个使用 perl6 的子集命令和一些专门针对这些类型的多子集构建的类型层次结构。当多分派发生时，如何为最窄子类型专门化的子提供最高优先级？

这是简化的代码：

我知道 R 中不同 OO 系统的一般来龙去脉，我愿意随时/尽可能长时间地呆在 S3 中。

但是，在过去的专业项目中，多次调度的需求一直困扰着我，并一直把我拉进 S4。

但我拒绝接受我找不到多调度的 S3仿真à la S4 至少能够支持我避免非系统数据漂移的主要用例：

1. 我的分析程序创建了我发布给利益相关者的数据结构，供他们作为某些数据管道的一部分使用
2. 通常我发布到诸如 MongoDB 之类的 DBMS，因此我的结构在某种程度上表现出来，并且可以/应该被认为是 DB 模式
3. 我遵循“尽早发布，经常发布”的方法来保持敏捷，所以“事情会发生变化”是很自然的——经常而且随着时间的推移
4. 随着数据结构的最终发展，我希望明确描述结构，以便我可以定义内部迁移例程和/或让利益相关者了解他们在数据库中处理的数据结构版本

如果我通过一些版本控制方案（这是迄今为止我能想到的最好的方案）来描述我的数据结构，我基本上需要将我的方法基于关于方法分派的三个签名参数：

1. 一个用于给定数据转换任务的输入（类）
2. 一个用于输入（类）的版本
3. 一个用于输出的版本（类）

尽职调查

除了我读过的OO 领域指南：

• subsetR中方法的多次调度
• Winston Chang 的多调度要点

我的方法

基于顺序 S3 的 aninput_class和 an方法output_class都可以随着时间的推移在结构上演变，由各自的版本类（例如v1等）捕获v2。

第 1 步：定义必要的基础组件

input_class = v1第 2 步：为和的初始情况定义方法output_class = v1

output_class第 3 步：处理to的演变v2

input_class第 4 步：处理to的演变v2

优点

1. 有用
2. 这是S3
3. 是系统的

缺点

1. 它比任何基于 S4 的解决方案都更加冗长
2. 我一点也不喜欢

有没有人想出更好的 S3 中的多调度仿真？

C++ 标准库在很多地方都提供了一种“可等待”的 API：例如std::future，std::condition_variable可以立即“尝试”获取它们的值，无限期地“等待”它们的值，“wait_for”某个std::chrono::duration，或“wait_until”某个std::chrono::time_point到达. 我正在努力创建一个捕获这些相同操作的抽象基类。

try并且wait没有问题。wait_for并且wait_until需要模板参数，因此不能是虚拟的。

有没有一种“干净”的方式来定义这样的接口？`

我考虑过的一些选项（除非我遗漏了什么）似乎不可行：

• 使用std::any或某种其他类型的擦除。在内部将duration对象传递给另一个函数时，我仍然需要知道正确的类型才能正确转换它。
• 使用访问者模式。这将要求我在一个中心位置指定从“Awaitable”派生的所有类型的硬编码列表，引入循环依赖并限制可扩展性。
• 使用std::duration_castandstd::time_point_cast将任何传入类型类型转换为std::chrono::nanosecondsor std::chrono::time_point<std::chrono::high_resolution_clock>，因此会有一个非虚拟模板化方法和一个虚拟非模板化方法。这似乎会引入不必要的开销和潜在的不当行为，因为我不确定是否保证每种可能的传入类型都可以转换为这些常见类型。

到目前为止，第三种变体似乎是我唯一的选择，而不是一个很好的选择。

主要问题很简单，真的。给定一个基类（更抽象的）和多个需要相互交互的派生类，你如何去做呢？

举一个更具体的例子，这里是一个 2d 视频游戏的 hitboxes 实现：

与头文件：

我对此的主要问题是每个派生类都需要在重写函数中进行的“is-a”检查。

我看到的替代方案是访问者设计模式，但这可能：

1. 对于这个看似简单的问题来说太复杂了。

2. 导致的问题多于解决方案。

该代码应该保留的一个特性是，没有派生类被强制实现与每个（或任何其他派生类）的交互。另一个是能够将所有派生对象存储在基本类型数组中而无需任何对象切片。