IB>>Возможно пользователю не нужно подписываться на события вычисляемой коллекции. Ему просто нужно чтобы всегда "под рукой" была вычисленная коллекция. Например, если вычисление сложное и\или коллекции источники большие, каждый раз вычислять коллекцию обычным LINQ не хочется по соображениям производительности. Например, есть Dictionaring. Его можно рассматривать как самообновляемый словарь, событий у него нет. Такой выигрыш в производительности ещё один сценарий использования OC, кроме событий. Кстати забыл упомянуть этот сценарий в документации.

S>Ну, это как бы совсем другой сценарий, чем описанный в документации.

S>И по-прежнему непонятно, чем плохо иметь результат с событиями, когда они не нужны. Не подписываешься — и всё.
Я о том, же: события в любом случае нужны, принимая во внимание сценарий описанный выше. Это был контр-аргумент к

S>К примеру, можно вообще не подписываться на события "завёрнутой" коллекции до тех пор, пока на наши события никто не подписан.

S>>>А размер памяти, потребляемой "observable" результатом select или where будет ненамного больше, чем у результата обычного linq-to-objects запроса.
IB>>То же надо оценивать.
S>А чего там оценивать? По отношению к "голому" результату, который приезжает из Linq2objects, в нём только 2 event-а, т.е. дополнительного места на 2 указателя. Копейки.
Кроме 2 указателей, у меня в каждом OC вычислении ещё полно потрохов. Ситуация по памяти может значительно ухудшиться, если присутствует параметрозависимое вложенное вычисление, например

sourceCollection1.Filtering(sc1i => sourceCollection2.ContainsComputing(sc1i).Value)

Здесь на каждый элемент коллекции sourceCollection1 будет создано отдельное вычисление ContainsComputing.

IB>>Возможно пользователю не нужно подписываться на события вычисляемой коллекции. Ему просто нужно чтобы всегда "под рукой" была вычисленная коллекция. Например, если вычисление сложное и\или коллекции источники большие, каждый раз вычислять коллекцию обычным LINQ не хочется по соображениям производительности. Например, есть Dictionaring. Его можно рассматривать как самообновляемый словарь, событий у него нет. Такой выигрыш в производительности ещё один сценарий использования OC, кроме событий. Кстати забыл упомянуть этот сценарий в документации.

S>Ну, это как бы совсем другой сценарий, чем описанный в документации.

S>И по-прежнему непонятно, чем плохо иметь результат с событиями, когда они не нужны. Не подписываешься — и всё.
Я о том, же: события в любом случае нужны, принимая во внимание сценарий описанный выше. Это был контр-аргумент к

S>К примеру, можно вообще не подписываться на события "завёрнутой" коллекции до тех пор, пока на наши события никто не подписан.

S>>>А размер памяти, потребляемой "observable" результатом select или where будет ненамного больше, чем у результата обычного linq-to-objects запроса.
IB>>То же надо оценивать.
S>А чего там оценивать? По отношению к "голому" результату, который приезжает из Linq2objects, в нём только 2 event-а, т.е. дополнительного места на 2 указателя. Копейки.
Кроме 2 указателей, у меня в каждом OC вычислении ещё полно потрохов. Ситуация по памяти может значительно ухудшиться, если присутствует параметрозависимое вложенное вычисление, например

sourceCollection1.Filtering(sc1i => sourceCollection2.ContainsComputing(sc1i).Value)

Здесь на каждый элемент коллекции sourceCollection1 будет создаваться отдельное вычисление ContainsComputing.