Ваши претензии насчёт «читаемости» кода лучше адресовать к архитекторам C#, которые ввели именно такую реализацию async...await с немалым количеством подводных камней.
Что касается написанного именно мной кода, то он весьма тривиален — это всего лишь цепочные вариации метода ForEach очень схожие с одноименным методом у класса List. То есть запросто без всяких дополнительных расширений сейчас можно писать такой код
new List<ADocument>() {...}
.ForEach(async d => await d.DoSomething());
Насколько понимаю, вы хотите сказать, что интуитивное добавление async...await ломает его читабельность?
Да, я ошибся с тем, что он должен выполняться параллельно, но при искуственном добавлении задержки в метод Load ничего в моей программе не сломалось и не заблокировалось, просто текст из файла загрузился чуть позже, из чего делаю вывод, что интуиция меня не подвела и работает код, по крайней мере, асинхронно, как и хотелось.
В конкретном случае главной вью-модели вообще не важен результат загрузки. Но, например, важен результат закрытия: в самом конеце файла, 81 строка, метод Close.
Благодарю за бенчмарки. Примерно таких результатов я и ожидал — всё в допустимых пределах, различия нет даже в десять раз. Одна и пять миллионных секунды — в подавляющем большинстве практических случаев неразличимы.
По fallbackValue, методу нужен булевый признак и он работает с value types, которые оператор 'as' не поддерживает.
Потому что нет лишних ресурсов.
Много же нужно ресурсов, чтобы вместо выражения object.Equals(...) подставить
EqualityComparer<T>.Default.Equals(...)
«Интересные вещи» — совсем не то же самое, что «обобщение».
Рассматриваемые интересные вещи уже довольно-таки обобщены на широкий круг сценариев.
Когда вы впервые видите какой-то метод, то зачастую не знаете деталей его имплементации — это нормально, вы просто смотрите код или читаете описание в документации.
public static IList<T> ForEach<T, TR>(
this IList<T> collection,
Func<T, TR> action)
{
foreach (var item in collection)
action(item);
return collection;
}
После этого многие вопросы пропадают, и вас уже не смущает этот же вызов в другом месте программы.
Ну так не читайте и не понимайте, никто здесь вас не принуждает чего-то делать. )
Просто ваша призыв выглядит сейчас так: «Не учите интегралы, они трудные, с ними легко ошибиться, и они, наверняка, не пригодятся вам в жизни. Пользуйтесь школьной математикой, она простая, понятная, хорошо применима на практике, и многие ей хорошо владеют».
Вся логика работы с файлом (или группой фалов) инкапсулирована внутри самого документа.
Основной вью-модели или кому-то ещё вообще не нужно знать, как конкретно документ работает с файлами или даже какими-то другими ресурсами, а уж тем более какие ошибки могут при этом возникнуть и как их обрабатывать.
Думаю, что развитие программирования идёт эволюционным путём. Как существуют различные царства живых существ, так и различные подходы к программированию.
Каждый подход имеет свои преимущества и недостатки, которые делают его более оптимальным или неоптимальным для тех либо иных задач. Равно как в определённых условиях одни виды жизни более успешны, чем другие, а в других условиях — наоборот.
Конечно, я обычный человек, который может ошибаться, но над архитектурой редактора размышлял очень много времени. Это не единственный возможный вариант, но он мне очень даже нравится.
Ваши претензии насчёт «читаемости» кода лучше адресовать к архитекторам C#, которые ввели именно такую реализацию async...await с немалым количеством подводных камней.
Что касается написанного именно мной кода, то он весьма тривиален — это всего лишь цепочные вариации метода ForEach очень схожие с одноименным методом у класса List. То есть запросто без всяких дополнительных расширений сейчас можно писать такой код
Насколько понимаю, вы хотите сказать, что интуитивное добавление async...await ломает его читабельность?
Да, я ошибся с тем, что он должен выполняться параллельно, но при искуственном добавлении задержки в метод Load ничего в моей программе не сломалось и не заблокировалось, просто текст из файла загрузился чуть позже, из чего делаю вывод, что интуиция меня не подвела и работает код, по крайней мере, асинхронно, как и хотелось.
По fallbackValue, методу нужен булевый признак и он работает с value types, которые оператор 'as' не поддерживает.
Много же нужно ресурсов, чтобы вместо выражения
object.Equals(...)подставитьРассматриваемые интересные вещи уже довольно-таки обобщены на широкий круг сценариев.
После этого многие вопросы пропадают, и вас уже не смущает этот же вызов в другом месте программы.
Просто ваша призыв выглядит сейчас так: «Не учите интегралы, они трудные, с ними легко ошибиться, и они, наверняка, не пригодятся вам в жизни. Пользуйтесь школьной математикой, она простая, понятная, хорошо применима на практике, и многие ей хорошо владеют».
Вся логика работы с файлом (или группой фалов) инкапсулирована внутри самого документа.
Основной вью-модели или кому-то ещё вообще не нужно знать, как конкретно документ работает с файлами или даже какими-то другими ресурсами, а уж тем более какие ошибки могут при этом возникнуть и как их обрабатывать.
1. Подготовили докуметы к работе
2. Асинхронно вызвали параллельную загрузку данных в каждый
Всё. Документы уже готовы к работе и сами разберутся, что делать при возникновении ошибок.
Каждый подход имеет свои преимущества и недостатки, которые делают его более оптимальным или неоптимальным для тех либо иных задач. Равно как в определённых условиях одни виды жизни более успешны, чем другие, а в других условиях — наоборот.
Многообразие — важный механизм эволиции. )
Конечно, я обычный человек, который может ошибаться, но над архитектурой редактора размышлял очень много времени. Это не единственный возможный вариант, но он мне очень даже нравится.