Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Serginio1, Вы писали:
I>>>Количество yield ничего не значит. IQueryable можно прикрутить поверх чего угодно. А раз так, то это и есть общий случай.
S>>А ну да молодец. То есть все твои примеры используют yield но ты переходишь на IQueryable. Но
S>>IQueryable<out T> : IEnumerable<T>, IQueryable
I>Ты пока не показал, как xml, db и подобные вещи читать твоим IEnumerable, что бы это было максимально эффективно.
Ты чего издеваешься!!! Я тебе ссылку на Linq to XML давал!!!!!
I>>>Браво, ты узнал, что Обсервер и Итератор дуальны, а раз так, то можно один сводить к другому.
I>>>Ровно то же можно написать и без yield, с таким же количеством кода.
I>>>вместо yield a будет observer.next(a)
S>> Дохрена чего можно только это все трудоемко.
I>В JS, раз уж ты вспомнил, есть yield. Однако же, в RX процессинг ленивый, а обходятся без yield
I>https://github.com/ReactiveX/rxjs/search?q=yield
I>Ажно 11 раз, и те в документации и тестах 
I>Теперь тебе понятно, что yield для RX это вещь сильно опциональная?
Еще раз писать ленивые итераторы это ручная работа того, что делает yield.
Что и как генерит yield копируй и вставляй в код. В свое врямя то же самое развертывался async await в JS
S>>То, что на C# делается в 2 строчки кода, в других надо писать кучу кода. Поэто в большинстве просто используют List
I>Покажи, где здесь куча кода:
I>https://github.com/ReactiveX/rxjs/blob/master/src/internal/operators/filter.ts
И что там фильтры. Аналог Where. Смотри реальный итератор
https://github.com/ReactiveX/rxjs/blob/23bc7fdc16acd76dd71a4faf57b8b949684c3249/src/internal/operators/OperatorSubscriber.ts#L7
В C# это 2 строчки
I>Ровно то же у тебя и в C#, в т.ч. OperatorSubscriber, т.к. ктото должен конвертить последовательность значений в последовательность эвентов.
S>> При чем тут IQueryable, слишком дорого его использовать для коллекций и смысла то особого нет, только лишние накладные расходы.
I>Дорого, я в курсе. Иногда это обосновано, если перформанс не актуален, а нужно иметь один и тот же код против разных источников данных.
S>>То ты ратуешь за скорость то сам добавляешь дополнительную сложность и тормоза
I>Ну и логика 
Я озвучиваю простой факт, а ты додумываешь, будто я весь код так пишу. Ты адекватен?
S>>>> Кто тебе запрещает писать расширения используя yield?
I>>>Ок. Покажи пров для mssql на yield. Валяй.
S>> Я тебе уже кучу привел примеров использования yield
I>То есть, слив Или ты считаешь свой код примерами работы с mssql ?
I>>>Покажи пров для mssql на yield. Хотя бы идею выдай.
S>> Да легко. Получаешь результаты порциями. Держишь на сервере энумератор. Итд
I> Каким образом по IEnumerable построить SQL ?
I>>>Без IQueryable не было бы, да. Именно это позволяет прикрутить Linq к чем угодно. А вот yield для BD — хоть раком встань, ничего не выйдет.
S>>Но деревья выражений не использутся для коллекций!!!
I>Используются, просто ты про это ничего не знаешь. Если код написан для BD, нет никакого смысла городить огород, если в некоторых случая нужно таскать данные из коллекций.
I>Используем один и тот же код против BD и коллекций, всех делов.
Я с тебя хренею. Почитай себя. Все твои доводы против yield.
yield это херня так как не используется в IQueryable. Но IQueryable хотя и не используется в IEnumerable хотя IQueryable наследуется от IEnumerable
Зачем использовать IQueryable для коллекций!!! Только для совместимости в итоге генерить Linq IEnumerable.
Не ну чувствуется подход к опитимизации по скорости!!!
