DB
Ну, попробовать сделать IEnumerableCached, в котором обернуть IEnumerable методы, выдавая нужный итератор из кэша. Только это прям как дрочить вприсядку. Занятие увлекательное, но бесполезное.
Size: a a a
2021 November 29
AS
*подСписки
AG
Так и не понял что это, типа тут внутри скрытого гета кешированный результат?
DB
Только мой вариант легко переделывается в ICollection/IEnumerable. При этом не требуется доп.метод, он масштабируем и т п.
AG
Хорошо, я понял что нормально и без кеширования линка. Я сам против излишней оптимизации, просто интересно было.
AS
Как только вызываются операции мутабельности. Например IList<Item>.Add(Item). Я выполняю логику этой операции плюс обновляю подсписки aItems и bItems
DB
Он типа не хочет получать руками итератор постоянно.
DB
Итератор вообще вроде как state machine. Для async/await, значит, не накладно создавать её, а итератор - всё, Содом и Гоморра, все в жёппы ипутся.
DB
При этом писать код, который заведомо немасштабируем и завязан на куда более "тяжёлом" IList - норм.
DB
Только ой, вот беда:
DB
Какой нехороший лист)))
DB
Создаёт итератор Энумератор на каждом вызове.
AS
Эм
В чем беда?
Что когда просишь лист создать итератор он его создает?
В чем беда?
Что когда просишь лист создать итератор он его создает?
DB
Так в чём тогда беда в моём коде, где не надо городить огород, а сделать get => items.Where(...).Select(...)?
DB
ReferenceEquals как бы не будет в обоих случаях.
AS
>Сделать items ObservableCollection, остальные массивы кешировать и обновлять при каждом изменении items уже лучше, но всё равно напряжно
Я попробовал предложить решение, которое может быть покажется автору менее напряжным, а делать будет то же. Ещё вопросы?
Я попробовал предложить решение, которое может быть покажется автору менее напряжным, а делать будет то же. Ещё вопросы?
DB
Окей. Я предложил ещё проще решение.
AS
С которым я лично согласен, если ты не заметил я написал его ещё до тебя, но делает оно другое
DB
Повторные вычисления здесь какие будут?