C#, как и любой другой язык программирования, это инструмент, который должен развиваться в месте со средой, где он применяется. По аналогии, вам никто не мешает использовать костяной скребок для разделки мяса, но человечество придумало более совершенные инструменты.
Более того, все новые фичи активно предлагаются и обсуждаются сообществом. Сначала в репозитории C# Language Design, а затем на внутренних митингах в Microsoft, протоколы которых регулярно выкладываются там же. Из чего делаем вывод, что все новые "штуки" не случайные, и исходят не только от Microsoft.
Но что было не так с обычным оператором switch?
Такой сокращенный синтаксис с оператором => начал проникать в язык еще с С# 3.0, где блок кода для делегата, состоящего из одного выражения, можно было заменить однострочником, избежав церемонии с фигурными скобками, return в случае функции, и ключевым словом delegate. Упрощение блока switch -- это логическое продолжение этой идеи. Так же как и expression-bodied members.
Но ключевое слово var уже достаточно спорно. Зачем второе?
Никогда не понимал этой претензии. Во-первых, ключевое слово var необходимо для работы с анонимными типами. Во-вторых, оно позволяет избежать дублирования типа в случае, когда тип очевиден исходя из выражения. Подобные конструкции уже есть в Java и C++.
Сокращенный оператор new без указания типа уже существовал для анонимных типов. Теперь его расширили для случаев, когда тип создаваемого объекта можно вывести однозначно, тем самым избежав дублирования, симметрично уже существующему var. Что особенно полезно для полей, где ключевое слово varне применимо.
В C# 10 вы можете создать свойство для свойства. Это называется поля C#.
Опять же, как и в других фичах, конкретно эта -- развитие идеи автоматических свойств. Теперь у вас есть прямой доступ к полю, что позволяет прописать дополнительную логику в get или set блоках (например, вызов события PropertyChanged), не объявляя при этом поле в явном виде. Так как поле недоступно извне этих блоков, никто не сможет его поменять в обход свойства, что в большинстве случаев полезно.
Как видите, все новые фичи -- это в той или иной мере развитие идей, заложенных в язык изначально.
Вспомнился момент из Uncharted 4, когда главгерои снимают пиджаки. Без трюков камеры и монтажных склеек. И это, кажется, чуть ли не единственный пример в играх когда одежда не привязана намертво к мешу персонажа.
Я не знаю, кто и как будет обрабатывать события, порожденные написанным мной классом, но мне не очень то хочется, чтобы эти обработчики могли повесить работу моего класса. Поэтому я буду использовать метод BeginInvoke вместо Invoke.
Если вам не хочется, чтобы обработчик повесил работу класса, то напишите такой обработчик — это нетрудно. Вместо этого, вы заранее ставите пользователя в рамки вашей странной асинхронной модели, и решаете проблему не с той стороны. А что, если в обработчике я захочу запустить асинхронную операцию, для которой не нужен лишний поток?
Более того, ваша реализация упирается в ограничения Thread Pool, и обработчики событий скорее всего выстроятся в очередь, в зависимости от загруженности пула; что еще хуже, пул может начать создавать новые потоки, которые неизбежно снизят производительность.
Учитывая, что IL сам по себе намного продвинутее Java байткода — c custom value types, не участвующими в сборке мусора, true generics без приведения типов, unsafe блоками кода с прямой манипуляцией указателями — я не понимаю, как JVM изначально может быть сильнее. На чем основано ваше утверждение?
C#, как и любой другой язык программирования, это инструмент, который должен развиваться в месте со средой, где он применяется. По аналогии, вам никто не мешает использовать костяной скребок для разделки мяса, но человечество придумало более совершенные инструменты.
Более того, все новые фичи активно предлагаются и обсуждаются сообществом. Сначала в репозитории C# Language Design, а затем на внутренних митингах в Microsoft, протоколы которых регулярно выкладываются там же. Из чего делаем вывод, что все новые "штуки" не случайные, и исходят не только от Microsoft.
Такой сокращенный синтаксис с оператором
=>начал проникать в язык еще с С# 3.0, где блок кода для делегата, состоящего из одного выражения, можно было заменить однострочником, избежав церемонии с фигурными скобками,returnв случае функции, и ключевым словомdelegate. Упрощение блока switch -- это логическое продолжение этой идеи. Так же как и expression-bodied members.Никогда не понимал этой претензии. Во-первых, ключевое слово
varнеобходимо для работы с анонимными типами. Во-вторых, оно позволяет избежать дублирования типа в случае, когда тип очевиден исходя из выражения. Подобные конструкции уже есть в Java и C++.Сокращенный оператор
newбез указания типа уже существовал для анонимных типов. Теперь его расширили для случаев, когда тип создаваемого объекта можно вывести однозначно, тем самым избежав дублирования, симметрично уже существующемуvar. Что особенно полезно для полей, где ключевое словоvarне применимо.Опять же, как и в других фичах, конкретно эта -- развитие идеи автоматических свойств. Теперь у вас есть прямой доступ к полю, что позволяет прописать дополнительную логику в
getилиsetблоках (например, вызов событияPropertyChanged), не объявляя при этом поле в явном виде. Так как поле недоступно извне этих блоков, никто не сможет его поменять в обход свойства, что в большинстве случаев полезно.Как видите, все новые фичи -- это в той или иной мере развитие идей, заложенных в язык изначально.
Если вам не хочется, чтобы обработчик повесил работу класса, то напишите такой обработчик — это нетрудно. Вместо этого, вы заранее ставите пользователя в рамки вашей странной асинхронной модели, и решаете проблему не с той стороны. А что, если в обработчике я захочу запустить асинхронную операцию, для которой не нужен лишний поток?
Более того, ваша реализация упирается в ограничения Thread Pool, и обработчики событий скорее всего выстроятся в очередь, в зависимости от загруженности пула; что еще хуже, пул может начать создавать новые потоки, которые неизбежно снизят производительность.