Здравствуйте, vdimas, Вы писали:
V>Всякий раз забавно видеть, как ты пытаешься примитивщину выдавать за откровения.
V>Лучше бы ты не маялся этой хернёй, а говорил тезисами, которые можно подтвердить или опровергнуть.


S>>IReadOnlySet, IReadOnlyList и прочие никакого отношения к иммутабельности не имеют.

V>Имеют такое же отношение, как и IImutableList и Ко.
V>Это высказывание — вполне себе тезис.
Ну да, совершенно верно. Это — ошибочный тезис.
Иммутабельность означает не просто отсутствие модифицирующих операций, но и наличие операций по построению новых значений на основе существующих.

V>Я на это уже отвечал — там речь лишь о некоторых алгоритмах над некоторыми иммутабельныим структурами данных.
Ткните пальцем хотя бы в один "алгоритм" в этом неймспейсе.

V>Есть несколько конекретных типов, помеченные как sealed, которые согласно дизайну являются иммутабельными.
А то.
V>А система реализованных интерфейсов — нет, это просто "вербальные соглашения".
Всё верно. Причём достаточно внятные вербальные соглашения. В принципе, любой интерфейс, помимо названий методов, оперирует некоторыми вербальным соглашениями. Нарушение которых компилятором не карается, но может привести к неожиданному поведению (в том числе и к багам).

V>Например, интерфейс IImutableDictionary может быть реализован не только на красно-чёрных деревьях.
А то. У нас с одногруппником в качестве курсовой работы была реализация IImmutableList и IImmutableDictionary на другой основе.
V>И может быть реализован не только в иммутабельном виде.
Может, но это всё сломает. А вот в read-only виде его реализовать эффективно очень затруднительно, если вообще возможно.

V>Что, однако, верно только для сценариев, где данные активно изменятся.
V>FrozenXXX были созданы для других сценариев — где данные читаются намного чаще, чем изменяются.
Да, для специального узкого случая.
Вы готовы навскидку сказать, насколько они эффективнее Immutable-аналогов?

V>* мы именно с тобой обсуждали N-арные деревья, т.е. ты должен хорошо понимать, что нет никакого запрета строить иммутабельные деревья из таких структур данных, сбалансированных с точностью от 1 до некоего выбранного max N узлов; т.е., при создании нового корня дерева в общем случае будут создаваться копии меньшего кол-ва узлов, чем для двоичных узлов, но в каждом узле будет больше элементов. До какого-то N это выгодная стратегия на современном оборудовании, потому что деревянная в памяти структура в общем случае обладает худшей локальностью, т.е. синтетические тесты, где в памяти только содаются узлы тестируемого дерева, могут сильно врать насчёт его эффективности.

Мы не просто это обсуждали. Я такую структуру реализовывал самостоятельно.

V>N-арное дерево в этом смысле — это обеспеченный ручками некий фактор локальности данных. В идеале, конечно, было бы удобно иметь ср-ва располагать такие "корзины" по границам кеш-линееек проца, но дотнету такие радости недоступны.
Прекрасно доступны, надо просто уметь их готовить.

V>В любом случае, рассуждать об иммутабельности или нет немспейса Frozen было заведомо глупо — типы данных там точно так же иммутабельны by design, как и в неймспейсе Immutable.
Тогда зачем вы притащили его обсуждение в эту ветку?