Что относительно дополнительных универсальных параметров типа в C# 5.0? [закрытый]
4 ответа
Я определенно за.
В настоящее время я пишу вспомогательные методы для различных сценариев, в которых я хочу передавать ссылки на разные члены и методы классов.Для этого я беру, например, Expression в качестве аргумента помощника (который позволяет мне обращаться к методу с помощью лямбда-выражения, сохраняя все строго типизированным) .
НО - в настоящее время мне нужно определить новый вспомогательный метод для каждого разного количества входных аргументов, поскольку мне нужно иметь разное количество общих аргументов для него. Вместо
HelperMethod<TIn>(Expression<Action<TIn>> arg) // Yes, C# can distinguish
HelperMethod<TOut>(Expression<Func<TOut>> arg) // these two from eachother
HelperMethod<TIn, TOut>(Expression<Func<TIn, TOut>> arg)
HelperMethod<TIn1, TIn2, TOut>(Expression<Func<TIn1, TIn2, TOut>> arg)
// etc
я мог бы обойтись максимум двумя методами:
HelperMethod<TIn>(Expression<Action<TIn>> arg)
HelperMethod<TOut, TIn1 = DummyType, ...>(Expression<Func<TIn1, ..., TOut> arg)
В моем случае это позволило бы избежать большого количества дублирования кода ...
Каково основное применение этой функции языка? Я вижу, что это могло бы помочь в некоторых административных задачах, таких как имена файлов и меньший набор текста и тому подобное, но помимо этого я не вижу, насколько это было бы полезно.
Кроме того, эта возможность значительно усложнит любые родовые ограничения, которые могут быть наложены на параметр родового типа, и сам тип по умолчанию должен будет функционировать как своего рода родовое ограничение.
Я думаю, что это усложнит язык, не предлагая никаких реальных преимуществ для разработчика.
Мне непонятно, что именно вы предлагаете. В настоящее время могут быть типы с одинаковыми именами, но с разными параметрами типов, но которые никак не связаны наследованием - что бы тогда сделало ваше предложение?
Кроме того, если бы библиотека базовых классов была переработана с нуля, почти наверняка не будет неуниверсального интерфейса IEnumerable - он существует только потому, что среда CLR не поддерживала универсальные шаблоны, когда интерфейс был представлен, а общий интерфейс наследуется от него только для того, чтобы унаследованный код продолжал работать. Недавно объявленные классы создаются для среды CLR, которая поддерживает универсальные шаблоны, поэтому эта проблема больше не актуальна.
Недавно я наткнулся на кейс, в котором можно было бы использовать что-то подобное, но не совсем. У меня был метод, который выполняет своего рода преобразование между классом A и связанным с ним классом AChild и классом B и классом BChild. Обычно пара A / AChild была такой же, как B / BChild, но иногда A был базовым классом B, а AChild - базовым классом BChild.
Было бы неплохо сказать, что для моего параметра типа TB по умолчанию задано значение TA, а для TBChild - TAChild.
Обратите внимание, что это была ситуация, в которой необходимо было записать параметры типа, поскольку логический вывод не работал.