Возможности C # или .Net отключить, если не требуется обратной совместимости? [закрыто]

Любой продукт или структура развивается. В основном это делается для того, чтобы удовлетворить потребности своих пользователей, использовать новые вычислительные мощности и просто сделать его лучше. Иногда основная цель дизайна также меняется вместе с продуктом. C # или .net Framework не является исключением. Как мы видим, сегодняшняя четвертая версия сильно отличается от первой. Но вещь становится баррикадой для этой эволюции - обратной совместимости.

В большинстве фреймворков / продуктов некоторые функции были бы отключены, если бы не было необходимости поддерживать обратную совместимость. По вашему мнению, что это за функции в C # /. Net?

Пожалуйста, укажите одну функцию в ответе.

Анонимные методы . Я думаю, что все согласны с тем, что синтаксис анонимного метода, выбранный для C # 2.0, является коренастым и неуклюжим по сравнению с синтаксисом лямбда, который мы добавили в C # 3.0. К сожалению, иметь два почти идентичных синтаксиса, чтобы делать одно и то же.

Я бы избавился от неуниверсальных коллекций. Это мерзость ... и слишком много случаев, когда я использую linq, и мне приходится делать что-то вроде

var customObjects = container.CustomObjects.Cast<CustomObject>();

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

пустота как тип . Почему «пустота» является типом? У него нет экземпляров, у него нет значений, вы не можете использовать его как аргумент универсального типа, тип формального параметра, локальный тип, тип поля или тип свойства. Это не имеет значения как тип; скорее это факт о том, какое влияние вызов метода оказывает на стек виртуальной машины. Но виртуальная машина - это просто виртуальная машина. Реальная машина поместит возвращенное значение в регистр (обычно EAX на x86) и не повлияет на стек вообще! Пустота как тип - плохая идея.

Хуже: при использовании в типе указателя, как в void* он означает что-то совершенно иное, чем тот, который используется в качестве возвращаемого типа. Теперь это означает «указатель на место хранения неизвестного типа», который не имеет никакого отношения к его значению как «метод, который не возвращает никакого значения».

Мы можем заменить void*как тип указателя на IntPtr. (Иvoid** с IntPtr*и так далее.) Мы можем заменить void в качестве возвращаемого типа на «Unit», тип, который имеет одно значение, а именно, null. Реализация CLR может затем решить, что вызов функции с типом модуля может оптимизировать использование регистров или стеков соответствующим образом, зная, что возвращаемый нуль можно безопасно игнорировать.

В таком мире вам больше не нужны отдельные Func<A, R>и Action<T>делегаты. Action<T>это просто Func<T, Unit>.

Пустое утверждение; . Подверженный ошибкам, почти всегда опечатка, и не дает вам дополнительного значения, которое еще не выражено {}.

Небезопасная ковариация на массивах ссылочного типа . При типизированной безопасной ковариации IEnumerable<T>, по крайней мере, отчасти исчезла необходимость в ковариации массивов. (Если бы у нас был ковариантный интерфейс списка, доступный только для чтения, он бы нам вообще не понадобился.)

Унарный оператор плюс . Наименее полезный оператор всех времен. Если бы нам не нужно было хранить это для обратного состязания, я бы вынул это в одно мгновение. Кто-нибудь использует эту вещь?

(Пояснение: унарный оператор плюс +xне является оператором прединкремента ++x, не оператором постинкремента x++и не оператором двоичного сложения x+y.)

По умолчанию числовые литералы double

Для большинства бизнес- приложений decimalэто в любом случае более уместно ... или, может быть, было бы лучше просто удалить идею по умолчанию и заставить разработчика фактически сделать выбор.

(Это «удалить значение по умолчанию» было бы уместно и для некоторых других вещей. Например, я прекратил пытаться убедить всех, что классы должны быть запечатаны по умолчанию, но я подозреваю, что легче убедить людей, что они должны думать о должен ли их новый класс быть запечатан или нет, и сделайте это явным.)

Это скорее руководство, чем функция, но я думаю, что это важно, потому что это уже слишком укоренилось в умах людей, как каноническое и лучшее решение:

Официальный шаблон для реализации IDisposable.

Это громоздко и есть лучшие способы .

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

Методы и типы Arrayи List<T>которые устарели с Linq, например:

• Array.TrueForAll можно заменить на Enumerable.All
• Array.FindAll можно заменить на Enumerable.Where
• List<T>.ConvertAll можно заменить на Enumerable.Select
• Predicate<T> можно заменить на Func<T, bool>
• Converter<T,R> можно заменить на Func<T, R>
• IComparer<T> действительно должен быть делегатом Func<T, T, int>

Неуниверсальные делегаты Как и неуниверсальные коллекции, неуниверсальные делегаты бесполезны теперь, когда у нас есть серии Func и Action. И я бы обрезал варианты по трем параметрам. Если у вас есть более трех параметров, создайте структуру и используйте ее в качестве единственного параметра. Объявление конкретного делегата для обработки событий не очень СУХО.

Веб-сервисы asmx

Я думаю, что они довольно устарели с WCF в настоящее время.

Winforms
Было бы неплохо не переходить между двумя настольными платформами. WPF - это то, куда идут дела, поэтому расстраивает полное резервирование на уровне платформы.