Комментарии 17
НЛО прилетело и опубликовало эту надпись здесь
Для того что бы это работало надо ставить заплатку на .NET 4.0 и к студии(либо переходить на VS2012).
НЛО прилетело и опубликовало эту надпись здесь
Да, это может быть большой проблемой для команды.
Всей команде придется патчить VS2010 либо переходить на VS2012. На всех конечных компьютерах надо быть уверенным не только в .NET 4.0 но в KB2468871. На всех билд/тест машинах должна стоять заплатка. В зависимостях к проекту надо не забыть о Microsoft.Bcl.Async.
О варианте с заплаткой и компиляцией из C# 5.0 под .NET 4.0 я уже писал в начале статьи.
Всей команде придется патчить VS2010 либо переходить на VS2012. На всех конечных компьютерах надо быть уверенным не только в .NET 4.0 но в KB2468871. На всех билд/тест машинах должна стоять заплатка. В зависимостях к проекту надо не забыть о Microsoft.Bcl.Async.
О варианте с заплаткой и компиляцией из C# 5.0 под .NET 4.0 я уже писал в начале статьи.
UPD: да, заплатка нужна.
«тимлид грозит небесной карой за смену платформы»
и правильно сделает! Следующий программист, кто будет работать с Вашим кодом, скажет: WTF!
И да: KISS! KISS, BABY!
и правильно сделает! Следующий программист, кто будет работать с Вашим кодом, скажет: WTF!
И да: KISS! KISS, BABY!
Не очень ново. После выхода .Net 2.0 много подобного появлялось.
Плюсы: красиво для того, кто понимает и автора. Минусы: некрасиво для остальных.
Когда «остальные» погружаются в код с yield и разбираются настолько, что «понимают», то онивступают в секту приравниваются к автору, заодно дописывая пару красивостей к библиотеке и коду.
А потом приходит тимлид/пм…
Плюсы: красиво для того, кто понимает и автора. Минусы: некрасиво для остальных.
Когда «остальные» погружаются в код с yield и разбираются настолько, что «понимают», то они
А потом приходит тимлид/пм…
Да, не спорю, баян. Но, он делает код с множеством вложенных «продолжений» или колбеков проще для восприятия.
Могу еще написать статью про нелегкое дело приведение/конвертации типов в .NET. Только в mscorlib и System.dll около 4х разных способов привести/сконвертировать один тип в другой. В бонус будет страшный классец(весь в генериках), который скрывает детали за одним интерфейсом: TypeConvert[Uri].From(«schema://localhost/»).
Могу еще написать статью про нелегкое дело приведение/конвертации типов в .NET. Только в mscorlib и System.dll около 4х разных способов привести/сконвертировать один тип в другой. В бонус будет страшный классец(весь в генериках), который скрывает детали за одним интерфейсом: TypeConvert[Uri].From(«schema://localhost/»).
Для меня yield — отложенное формирование IEnumerable
Напишите, пожалуйста, «остальным» круг задач для которых нужно использовать yield кроме формирования IEnumerable в production коде.
Ну если не IEnumerable, то это магия какая-то…
Напишите, пожалуйста, «остальным» круг задач для которых нужно использовать yield кроме формирования IEnumerable в production коде.
Ну если не IEnumerable, то это магия какая-то…
Помимо генератора(основное предназначение) на yield можно собрать сопрограмму(выше) и конечный автомат. Это то что впомнилось в первую очередь, а так только фантазия(и тимлид) может ограничить область применения.
Если ведется разработка desktop-приложения (Microsoft .NET Framework 4.0, Microsoft Visual Studio 2012), то для решения описанной задачи, можно использовать альтернативное решение от компании Microsoft в виде дополнительной библиотеки: описание проекта, пакет NuGet. Минус: дополнительная библиотека (~65KB). Плюс: код использования
async/await полностью повторяет таковой для Microsoft .NET Framework 4.5, при переходе на новую версию просто убирается ссылка на библиотеку.
Штука достаточно мощная. Например, в новом питоне предлагается на таких «корутинах» написать целый стэк для написания вёб-серверов (и не только их). К сожалению, в C#5.0, как это видно,
yield return сильно ограничен тем, что а) ничего не возвращает извне и б) не дружит с try {..} catch {..}.У питоновцев уже есть технология continuation (stack-less Python) которая дает больше контроля над потоком исполнения и меньше проблем с продумыванием точек выхода/возврата через yield. А по поводу недостатков дотнетовского yield, то а) можно прокинуть «канал» с входящей информацией через аргументы б) try/catch работает, но с ограничениями на возможность yield внутри блока. и да, это не побороть
Сразу вспомнилась библиотека Rx.NET.
Странный какой-то тимлид, если запрещает или не планирует переход на .NET 4.5.
Я сам тимлид, задача по переводу проекта на .NET 4.5 шла именно от меня.
Перевод прошел быстро и без серьезных проблем.
Потом запустили рефакторинг существующего кода по работе с асинхронностью, а так же перевод методов сервисов только на async.
Вы даже не представляете на сколько чище и понятнее стал код с переходом на async/await (особенно кода ушли IAsynResult, события т.д и).
Я сам тимлид, задача по переводу проекта на .NET 4.5 шла именно от меня.
Перевод прошел быстро и без серьезных проблем.
Потом запустили рефакторинг существующего кода по работе с асинхронностью, а так же перевод методов сервисов только на async.
Вы даже не представляете на сколько чище и понятнее стал код с переходом на async/await (особенно кода ушли IAsynResult, события т.д и).
Поэтому я люблю С++ и сопутствующий ему Qt, в котором так хорошо пропагандированны сигнал-слоты (async вызовы — альтернатива колбекам)
Асинхронный итератор Рихтера. Правда уже на тасках.
channel9.msdn.com/blogs/charles/jeffrey-richter-and-his-asyncenumerator — тут более подробно.
channel9.msdn.com/blogs/charles/jeffrey-richter-and-his-asyncenumerator — тут более подробно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Они смеются над твоими колбеками или async/await «для бедных»