Что серьезным основаниям состоят в том, чтобы жаль, что дженерики.NET не могли наследовать один из универсальных типов параметра?

Question

Что серьезным основаниям состоят в том, чтобы жаль, что дженерики.NET не могли наследовать один из универсальных типов параметра?

Это сообщение находится в продолжении этого.

Я пытаюсь понять, являюсь ли я единственным, кто пропускает и нуждается в способности.NET универсальный тип для наследования одного из его универсальных типов параметра.

Проблема состоит в том, чтобы собрать неопровержимые доводы в пользу этой функции или, альтернативно, узнать это нет ни одного.

Я привожу свою причину, чтобы иметь его, как ответ на этот вопрос - видит ниже.

Я прошу, чтобы люди там добавили их как ответы на это сообщение.

Если Вы не соглашаетесь, что функция полезна, или не имейте никаких серьезных оснований за - воздержитесь от регистрации чего-либо здесь, хотя можно сделать так в исходном сообщении, которое запустило все это - здесь.

P.S.

Некоторые шаблоны C++ не важны в.NET. Например, в его превосходной книге современный Дизайн C++ Andrei Alexandrescu описывает, как создать список типов, оцененных во время компиляции. Естественно, этот шаблон не важен для.NET, где, если мне нужен список типов, я просто создаю List и заполните его с типами. Так, давайте попытаемся придумать причины, подходящие для платформы.NET и не просто вслепую переводящий методы кодирования C++ в C#.

P.P.S.

Конечно, это обсуждение является строго академическим. Даже если сто неопровержимых доводов рассматриваемой функции появляются, это не будет реализованным, никогда.

16

.net generics

задан 5 revs, 2 users 98% 23 May 2017 в 12:02

2 ответа

Другие вопросы по тегам:

.net generics

Похожие вопросы:

score 0 · Answer 1

Хотя я понимаю, к чему вы клоните, это похоже на частный случай более общей проблемы плохой поддержки конструирования типов через композицию в .NET. . Было бы достаточно подхода, описанного на https://connect.microsoft.com/VisualStudio/feedback/details/526307/add-automatic-generation-of-interface-implementation-via-implementing-member для вас?

score 0 · Answer 2

Основное правило универсальных типов, которое предотвращает это, - «содержимое универсального типа должно быть четко определено в универсальном аргументе». Давайте посмотрим, как это применимо к следующему коду:

public abstract class AbstractBase
{
    public abstract string MyMethod();
}

public class SomeType<T> : T
{
}

public class SomeUsage
{
    void Foo()
    {
        // SomeType<AbstractBase> does not implement AbstractBase.MyMethod
        SomeType<AbstractBase> b = new SomeType<AbstractBase>();
    }
}

Итак, мы пытаемся реализовать MyMethod () :

public class SomeType<T> : T
{
    public override string MyMethod()
    {
        return "Some return value";
    }
}

public class SomeUsage
{
    void Foo()
    {
        // SomeType<string> does not inherit a virtual method MyMethod()
        SomeType<string> b = new SomeType<string>();
    }
}

Итак, давайте сделаем требование, чтобы T было производным от ] AbstractBase :

public abstract class DerivedAbstractBase : AbstractBase
{
    public abstract string AnotherMethod();
}

public class SomeType<T> : T
    where T : AbstractBase
{
    public override string MyMethod()
    {
        return "Some return value";
    }
}

public class SomeUsage
{
    void Foo()
    {
        // SomeType<DerivedAbstractBase> does not implement DerivedAbstractBase.AnotherMethod()
        SomeType<DerivedAbstractBase> b = new SomeType<DerivedAbstractBase>();
    }
}

Резюме:

К тому времени, когда вы учитываете все ограничения в базовых типах, вы настолько ограничены, что вывод из универсального параметра бессмысленно.