.net - 希望 .NET 泛型可以继承其中一种泛型参数类型的充分理由是什么？

Question

这篇文章是 this one 的延续.

我试图了解我是否是唯一一个错过并需要 .NET 泛型类型继承其泛型参数类型之一的能力的人。

面临的挑战是收集支持此功能的令人信服的理由，或者，要知道没有。

我给出了将它作为这个问题的答案的理由——见下文。

我要求那里的人们将他们的答案添加到这篇文章中。

如果您不同意该功能有用或没有充分的理由支持 - 请不要在此处发布任何内容，尽管您可以在开始这一切的原始帖子中这样做 - here .

附言

一些 C++ 模式在 .NET 中是不相关的。例如，在他的优秀著作 Modern C++ Design Andrei Alexandrescu 描述了如何创建在编译时评估的类型列表。自然，这种模式与 .NET 无关，如果我需要类型列表，我只需创建 List<Type>并用类型填充它。因此，让我们尝试找出与 .NET 框架相关的原因，而不是盲目地将 C++ 编码技术转换为 C#。

附言

当然，这种讨论是严格的学术性的。即使有一百个令人信服的理由来说明所讨论的功能，它也永远不会被实现。

Answer 1

我时不时地偶然发现一个实现问题，对此我深感遗憾 C<T>不能继承 T .不幸的是，我从未记录过这些问题，所以我只能描述最近的一个——我现在偶然发现的一个。所以这里是:

我们的系统可以通过元数据进行扩展，元数据在运行时可用。元数据被转换为在运行时使用 Reflection.Emit 动态生成的类型。不幸的是，动态生成的类型必须满足以下条件:

它必须派生自其他类型，作为参数提供给动态类型创建者。这种类型称为 祖先类型 并且始终是静态编译的类型。

它必须实现几个接口(interface)，比如IDynamicObject (我们的界面)，System.ComponentModel.INotifyPropertyChanged和 Csla.Core.IMobileObject .请注意，此条件对祖先类型施加了某些限制。例如，祖先类型可能不实现 IDynamicObject接口(interface)，除非所有接口(interface)方法都是抽象实现的。还有其他约束，所有这些都必须检查。

它应该(并且确实)覆盖 object方法Equals , ToString和 GetHashCode .

目前，我必须使用 Reflection.Emit 来发出所有 IL 代码以满足这些条件。当然，有些任务可能会被转发给静态编译的代码。例如， object.Equals(object) 的覆盖方法调用 DynamicObjectHelper(IDynamicObject, IDynamicObject)这是一个静态编译的 C# 代码，完成了大部分工作
比较两个动态对象是否相等。但这更像是一个异常(exception)而不是规则 - 大部分实现都是发射的，这是一个痛苦的屁股。

能写一个泛型类型不是很好吗，比如 DynamicObjectBase<T>哪个将使用祖先类型实例化并用作动态生成类型的实际基类型？在我看来，泛型 DynamicObjectBase<T>可以在静态编译的 C# 代码中实现大部分动态类型要求。动态发出的类型会继承它，并且可能只是覆盖一些简单的虚拟方法。

最后，我令人信服的理由是让 C<T>继承自 T将大大简化发出动态类型的任务。