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

18

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

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

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

Gulshan
источник
Ключевое слово new
Неманья Трифунович
4
Вопрос явно не конструктивен в соответствии с руководящими принципами и явно конструктивен на основе фантастических ответов. Голосование для повторного открытия.
PSR
1
позор это закрыто, все еще возможно Эрик будет вести блог вместо того, чтобы отвечать здесь?
JK.

Ответы:

35

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

Эрик Липперт
источник
1
Согласен, анонимные методы были хороши, когда у нас не было лямбд ... теперь они просто избыточны.
Майкл Браун
9
Есть одна особенность анонимных методов, которая намного лучше, чем лямбда-выражения ... их идеальное имя !!
исследовать
1
На данный момент я даже не помню синтаксис для анонимного метода в C #. Я должен был бы искать это, если бы по некоторой причудливой причине мне нужно было использовать один вместо лямбды.
Kyralessa
33

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

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

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

Майкл Браун
источник
Это слишком здорово.
1
Не все порты .NET поддерживают Generics. .NET Micro является примером. Может не применяться, если CustomObjects никогда не перейдет на эту платформу.
goodguys_activate
2
В этом преимущество отсутствия души.
CaffGeek
29

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

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

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

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

Эрик Липперт
источник
4
... и Taskпросто Task<Unit>. Повторное выполнение библиотечных битов асинхронной CTP заставило меня действительно пожелать этого ...
Джон Скит,
24

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

Эрик Липперт
источник
7
Не говоря уже об огромном снижении производительности под 64-битным JIT </ snark>.
Джесси С. Slicer
7
Пустое утверждение имеет снижение производительности? Это почему?
Квентин Старин
22

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

Эрик Липперт
источник
Я собирался записать это, когда увидел название вопроса - вы меня опередили :(
Крис Смит,
1
Полезно получить возможность получать ковариантную ссылку на массив и безопасно записывать ссылки на массив, которые были прочитаны из него . Если он IList<T>унаследован от IReadableList<out T>и не является универсальным IPemutable, он может поддерживать такие вещи, как сортировка, но массивы поддерживают его легче.
Суперкат
14

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

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

Эрик Липперт
источник
1
для (int i = 0; i <потолок; i ++)
Майкл Браун
13
Он не говорит о прединкременте и postincrement операторов: он говорит о одноместный плюс, противоположности отрицательного знака числа: +1 == 1. Это чертовски близко к неоперативному.
Джесси С. Slicer
8
Это не только о влиянии на машиночитаемом выход, он может улучшить внешний вид кода для людей: if(a == +1 || a == -1){...}.
Томас Братт
5
@ShuggyCoUK: Что особенно странно, так это то, что он перегружен . Потому что это часто случается. Вы знаете, как вы пишете некоторый JavaScript, и вы думаете , что человек, я бы хотел, чтобы JS позволил мне сделать пользовательскую семантику унарных операторов плюс, как это делает C # .
Эрик Липперт
2
@Eric Я не понял, что это было перегружено. вау, ты мог бы сделать с ним какую-то
мерзкую
12

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

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

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

Джон Скит
источник
Возможно, я бы склонялся к идентификации литералов, которые подразумевают значение, которое не может быть точно представлено как double / float ...
ShuggyCoUk
Если они относятся к Java - отошлите их к священным текстам Джошуа Блоха «Дизайн или документ для наследования или запретите их» martinfowler.com/bliki/DesignedInheritance.html IIRC kotlin по умолчанию закрывает классы, поэтому индустрия движется лучшее направление в этом отношении.
Элазар Лейбович
Почему занятия должны быть запечатаны?
Джеймс
@James: Именно по причинам, которые дает Джош. Разработка класса, который обеспечивает разумное и последовательное наследование, требует времени - а делать это, не зная, как будет использоваться наследование, еще хуже.
Джон Скит
1
@Pacerier: подумайте об неизменности, например. Незапечатанный класс не может претендовать на неизменность, так как подклассы могут вводить изменчивость.
Джон Скит
7

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

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

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

Jordão
источник
6

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

nikie
источник
4

Методы и типы 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>
nikie
источник
3
Мне нравится, Predicate<T>потому что он фиксирует намерение о том, как используется функция, и экономит немного текста.
Зеби
2

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

Майкл Браун
источник
3
Как бы вы определили делегата для метода, который принимает ref int с помощью Action или Func? Как бы вы определили комбинатор с Func? То есть нельзя сказать «делегировать DD (D d)»; с функционалом.
Эрик Липперт
2
хм ... я стою исправлено. Вот почему я оставляю работу по созданию инструментов, которые я использую, в ваших умелых руках;)
Майкл Браун
@EricLippert: Я хотел бы видеть специальный класс делегатов, который бы через магию CLR содержал делегаты "каждого" арности и комбинацию значений / ссылочных параметров [поиск делегата в магическом классе с соответствующим образом отформатированным именем создаст type], и ​​все делегаты правильной подписи наследуются от этого. Код, для которого нужен конкретный делегат, по-прежнему требует точного типа, но код, который требует конкретной подписи, может использовать магическое имя.
Суперкат
-1

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

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

fretje
источник
6
Да, но иногда намного легче уклоняться. , ,
Уайетт Барнетт
-2

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

Морган Херлокер
источник
Winforms кажется намного более стабильным, быстрым и менее глючным, чем WPF ...
Pacerier
Когда вам просто нужно взломать маленькое настольное приложение, WPF сильно излишним.
Kyralessa
Похоже, что между ними WPF устарел в пользу WinRT. Однако мне кажется, что Winforms более активен, чем WPF в развитии бизнеса. См. Также stackoverflow.com/questions/913417/…
Док Браун