Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Еще раз. Оно не делает ее иммутабельной, оно делает ее чистой. Мутабельность внутри сохраняется, но на чистоту не влияет, потому что нет видимого изменения состояния.
Ну, вот я тупой, не понимаю. Мне нужна не чистота, а определённая функциональность.
Я пишу функцию, которая, скажем, получает словарь и список пар, и возвращает словарь и список пар (так, чтобы бывшая голова списка была теперь добавлена к словарю, а список сократился на один элемент).
При этом мне иммутабельность важна — потому что этот словарь и список я передаю куда-то ещё.
И мне важна производительность, поэтому мне не шибко импонирует идея порождать полную копию структур на каждый чих.

Здравствуйте, Sinclair, Вы писали:

V>>Для методов структур это readonly.
S>О, прикольно. Про этот — не знал. Интересно, как всё это чудо ведёт себя при вызове внешних методов. И вообще, статья написана максимально мутно. Сначала пишут, что если метод обращается только к readonly мемберам, то защитной копии не создаётся. И тут же идёт абзац про то, что immutable structs всё-таки быстрее. Непонятно, чему верить.
S>Короче, надо экспериментировать.

Ну, ты правльно говорил, что можно добиться даже ухудшения, если по in-аргументу дёргать не-readonly мемберы, т.к. возможно неявное создание копий, если джит не заинлайнил такой метод с забытым readonly.

В плюсах аналогично — мешанина из const и не const ссылок приводит к созданию временных копий объектов, если оптимизатору недостаточно информации.

Т.е., если уж распространять константность, то делать это надо до абсолюта.
Например, в плюсах считается ошибкой стиля, если де-факто const метод или ссылочный параметр не был помечен как const (исключения составляют переопределения уже заданных сигнатур виртуальных методов).

Еще присутствует неудобство неразличимости сигнатур.
В плюсах это разные методы:

struct S1 {
    void Foo();
    void Foo() const;

    void Bar(int & value);
    void Bar(const int & value);
}

В дотнете ошибка компиляции:

struct S1 {
    void Foo() {}
    readonly void Foo() {}

    void Bar(ref int value) {}
    void Bar(in int value) {}
}

Здравствуйте, Sinclair, Вы писали:

S>При использовании Pointer<T> есть шанс вернуться к Expression, и использовать альтернативные компиляторы их в MSIL для ускорения.

Насколько я понимаю, Expression<T> в любом случае способно породить лишь делегат при компиляции.
Ты собираешься копировать тело target-метода делегата?

Здравствуйте, Sinclair, Вы писали:

V>>Разве что рекурсию при вызове Node.get_Item[index] можно заменить на цикл.
S>Ну, решение имеет право на жизнь. Лёгким движением руки можно склонировать https://githib.com/evilguest/atropos и сделать в него коммит. По коммиту все бенчмарки запускаются автоматически; примерно минут через 20-30 после коммита можно смотреть на графики.

Да я когда-то играл с иммутабельными коллекциями в дотнете с подачи Wolfhound — они всё-равно работали медленнее copy-on-write.
В моих сценариях разделяемые м/у потоками данные читаются во много раз чаще их обновления, т.е. скорость доступа к элементу по чтению была определяющей, а эта скорость для банального массива несравнима с логарифмическим доступом к элементу в деревьях.

И проблема не только в логарифмичности — даже если элемент найден в первом же узле дерева, то даже такой случай слишком проигрывает обычному массиву.

Здравствуйте, Sinclair, Вы писали:

S>При этом мне иммутабельность важна — потому что этот словарь и список я передаю куда-то ещё.

Не очень понятно. Передавай безопасный контракт, внутри держи мутабельную структуру.

Здравствуйте, vdimas, Вы писали:

V>Ты собираешься копировать тело target-метода делегата?
Я и так строю делегат. Если внутри — только safe код, то его, теоретически, можно конструировать из Expression. А если unsafe — то только руками.

Здравствуйте, vdimas, Вы писали:

V>И проблема не только в логарифмичности — даже если элемент найден в первом же узле дерева, то даже такой случай слишком проигрывает обычному массиву.
В листе B+ дерева внутри лежит обычный массив. Для размеров до 16 элементов доступ не слишком отличается от List<T>. Если отказаться от fancy stuff типа операторов, то можно вообще наружу выставлять прямо сам узел дерева, и убрать лишний уровень косвенности. Для больших размеров начинает сказываться copy on write.

Ну, и в целом, иммутабельные коллекции делаются не для того, чтобы быть быстрее императивных, а для того, чтобы реализовывать логику. В частности, с ними не нужны блокировки при многопоточной работе.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Здравствуйте, Sinclair, Вы писали:

S>>При этом мне иммутабельность важна — потому что этот словарь и список я передаю куда-то ещё.

НС>Не очень понятно. Передавай безопасный контракт, внутри держи мутабельную структуру.
Классика жанра — рекурсивные алгоритмы. Я в каждую ветку рекурсии передаю копию "текущего" словаря, тот его модифицирует и передаёт дальше. Благодаря иммутабельности у меня бесплатные откаты.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
S>>Кстати я тут уже писал
S>> В Delphi есть возможность объявить за реализацию класса свойство класса реализующего этот интерфейс (Implements).
S>>https://www.delphiplus.org/programirovanie-v-srede-delphi-for-net/direktiva-implements.html
S>Я в курсе
S>>Но по сути это аналог множественного наследования в C++
S>По сути это встроенная поддержка агрегации в COM.
Это понятно. Я к тому, что множественное наследование это набор полей структур https://logic.pdmi.ras.ru/~smal/aptu/cpp10/2010_12_03.html
с наследованием методов этих структур https://habr.com/ru/post/445948/
Через SD легко сделать аналог множественного наследования для структур. Проще взаимодействовать с нативным кодом

Здравствуйте, Sinclair, Вы писали:

S>Ну, и в целом, иммутабельные коллекции делаются не для того, чтобы быть быстрее императивных, а для того, чтобы реализовывать логику. В частности, с ними не нужны блокировки при многопоточной работе.
Ну можно всегда же прийти к версионности! У каждой версии свой набор страниц и листов.

Здравствуйте, Sinclair, Вы писали:

S>Благодаря иммутабельности у меня бесплатные откаты.

"Бесплатные" в данном случае очень даже платные.

Здравствуйте, Serginio1, Вы писали:
S> Это понятно. Я к тому, что множественное наследование это набор полей структур https://logic.pdmi.ras.ru/~smal/aptu/cpp10/2010_12_03.html
S>с наследованием методов этих структур https://habr.com/ru/post/445948/
Я в курсе, что такое множественное наследование. Не нужно приводить ссылки на помоечные статьи — тем, кто знает, как устроено МН, они не нужны, а тех, кто не знает, они ничему полезному не научат.
S>Через SD легко сделать аналог множественного наследования для структур. Проще взаимодействовать с нативным кодом
Непонятно, для чего делать множественное наследование для структур, и что за нативный код на него рассчитывает.

Давайте начнём не с конца, а с начала: что за пробему мы хотим решать? Не "делать МН через SG", и не "реализовывать МН для структур", а что за задача у вас стоит?

Здравствуйте, Serginio1, Вы писали:
S> Ну можно всегда же прийти к версионности! У каждой версии свой набор страниц и листов.
Не то, чтобы "всегда". Да, одним из методов реализации иммутабельности является версионирование ссылок.
Но это решение зачастую создаёт больше проблем, чем решает. В частности, не всегда понятно, когда уже можно удалять мусор.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>"Бесплатные" в данном случае очень даже платные.
Помог бы пример кода с memoize вокруг мутабельной коллекции, который бы показал преимущества этого подхода.

Ну, например, https://ericlippert.com/2014/10/13/producing-combinations-part-one/

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Например в метод add суем логику обнуления контейнера.

НС>Кто и зачем сует в метод add логику обнуления контейнера?

Вот бы узнать Я встречал такой код. Итого — как тут интерфейсы помогли?
Как будешь вызывать метод add? Будешь предполагать следование описанию, или подстраховыватся типа "если после добавления длина изменилась непойми как..."

НС>>>У любой технологии есть свои недостатки. Вывод то какой? Не использовать ООП?
I>> наоборот. Если ты понаимплементил интерфейсов это по факту отказ от ооп.

НС>Нет.

Это нарушение всех принципиов вместе взятых, а раз так, то это отказ от ооп.

I>>Непонятно, что ты имеешь ввиду.

НС>Я тут рядом ссылочку дал. Там поподробнее.

С глубокой иерархией интерфейсов все ровно так же. Например, если в иерархии, построеной на иммутабельный принципах, ты решил сделать базовый класс мутабельным, появляются ровно те же проблемы. То есть, ломается всё, что имеет хоть какую то реализацию или же использование.
yo-yo, который упоминается, точно так же имеет место с запутаной иерархией интерфейсов.

I>>- вот ты видишь, что интерфейс иммутабельный и в доке прямо сказано.

НС>Нет, не вижу. Нет такого свойства у интерфейса, оно им ортогонально.

У интерфейса вообще — нету. А вот смысл конкретной абстрации вполне себе может быть в иммутабельности. Например, иммутабельные структуры данных — списки например.
Как будешь использовать такой список, будешь полагаться на свой же дизайн, или будешь подозревать наследников во всех грехах?

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

Именно — не может. А раз не язык даёт гарантии, то кто их предоставит?
Кто же даст гарантию, что иммутабельный по дизайну список не имеет мутабельных операций?

I>>Так покажи этот выбор, как ты обеспечишь ту самую гарантию.
НС>Ты пытаешься лишить меня выбора, зачем то навязывая мне потребности в гарантиях иммутабельности.

Это просто пример. Любое свойство так же хорошо для иллюстрации, как и иммутабельность.
Можем взять еще проще — как ты обеспечишь гарантии, что add добавляет в конец списка свой параметр и вытекающие свойства — длина увеличивается на единицу и тд.

И снова тот же вопрос — когда ты вызываешь этот метод add, ожидаешь ли ты, что некто возьмет да и сделает "кастомную реализацию", а именно — очистку списка внутре этого add.
Ну то есть, пишешь ли логику вида "если после добавления список превратился в непойми что...". Самое главное — почему.

I>>Как и везде — компилятор, дизайн, тесты и тд.
НС>И каким образом компилятор назначил иммутабельность внятной, а контроль на null — нет? Можешь пояснить?

Элементарно — компилятор, например, может вычислить изменение свойства. Это ведь его работа, вычислять констреинты.
Если у тебя есть такой компилер, пожалуйста, пользуйся.

I>>Тогда показывай пример, если тебе есть чего сказать.
НС>Чайники Рассела полетели? Это ты давай доказывай, что subtype проблему решит.

А я тебе именно это и показываю, что твой вариант с интерфейсами обладает ровно теми же проблемами, как и с наследованием.
Нет проблем только с теми интерфейсами, которые никто не реализует и не вызывает.
Ты уже наполовину согласился с этом, "абсолютных гарантий ни одна конструкция языка не дает и дать не может"

Кстати говоря, по твоей же ссылке в качестве решения этих же проблем указыается этот самый subtype. Похоже, ты нечитатель, лепишь ссылки не глядя.

Здравствуйте, Sinclair, Вы писали:

S>Но это решение зачастую создаёт больше проблем, чем решает. В частности, не всегда понятно, когда уже можно удалять мусор.
Ну у тебя на каждом витке рекурсии своя версия а так же вложенность. можно управлять количеством вложенности и окончанием рекурсии

Здравствуйте, Sinclair, Вы писали:

S>Давайте начнём не с конца, а с начала: что за пробему мы хотим решать? Не "делать МН через SG", и не "реализовывать МН для структур", а что за задача у вас стоит?
Ну как я писал это может быть и дженерики структуры для расширения, а так же структур состоящих из наследования С++ шаблонов.
Я все про использование манагед кода на сервере и аля сингулярити мечтаю! То есть из маршалинга максимум копирование результата в памяти, можно просто результат сразу класть в определенную память. Пока все грусно.

Здравствуйте, Ikemefula, Вы писали:

НС>>Кто и зачем сует в метод add логику обнуления контейнера?
I>Вот бы узнать Я встречал такой код. Итого — как тут интерфейсы помогли?

Очевидно — никак. А должны были?


НС>>>>У любой технологии есть свои недостатки. Вывод то какой? Не использовать ООП?
I>>> наоборот. Если ты понаимплементил интерфейсов это по факту отказ от ооп.
НС>>Нет.
I>Это нарушение всех принципиов вместе взятых

Нет.

I>С глубокой иерархией интерфейсов все ровно так же.

Нет.

I>Например, если в иерархии, построеной на иммутабельный принципах

Иммутабельность никогда не была тем, что ОО контракты гарантируют.

I>>>- вот ты видишь, что интерфейс иммутабельный и в доке прямо сказано.
НС>>Нет, не вижу. Нет такого свойства у интерфейса, оно им ортогонально.
I>У интерфейса вообще — нету.

На этом разговор можно и закончить.

I>А вот смысл конкретной абстрации вполне себе может быть в иммутабельности.

При чем тут наследование и интерфейсы?

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

Ну да, вернулись к "раз мы всех воров поймать не можем, то нефик их вообще ловить".

НС>>Ты пытаешься лишить меня выбора, зачем то навязывая мне потребности в гарантиях иммутабельности.
I>Это просто пример.

Нет, это не просто пример. Если выкинуть ммутабельность — в твоих аргументах и построениях вообще ничего не останется.

I>Можем взять еще проще — как ты обеспечишь гарантии, что add добавляет в конец списка свой параметр и вытекающие свойства — длина увеличивается на единицу и тд.

На уровне ОО контрактов? Очевидно никак.

I>>>Тогда показывай пример, если тебе есть чего сказать.
НС>>Чайники Рассела полетели? Это ты давай доказывай, что subtype проблему решит.
I>А я тебе именно это и показываю,

Нет, никакого решения проблоемы ты не показывал. Исключительно пытался показать, что ОО контракты не контролируют иммутабельность, хотя с этим никто и не спорил. Возражение тут вызывает то, что ты назначил отсутствие контроля иммутабельности главным недостатком наследования.

I>Кстати говоря, по твоей же ссылке в качестве решения этих же проблем указыается этот самый subtype. Похоже, ты нечитатель, лепишь ссылки не глядя.

Нет, это ты споришь с воображаемым собеседником. Опять.

Здравствуйте, Serginio1, Вы писали:

S> Я все про использование манагед кода на сервере и аля сингулярити мечтаю! То есть из маршалинга максимум копирование результата в памяти, можно просто результат сразу класть в определенную память.

Тебе зачем? Какую реальную проблему ты хочешь этим решить?

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>Вот бы узнать Я встречал такой код. Итого — как тут интерфейсы помогли?

НС>Очевидно — никак. А должны были?

Именно. И с наследованием ровно так же.

I>>Это нарушение всех принципиов вместе взятых
НС>Нет.

Тут стоит посмотреть Skott Meyers, Herb Sutter, Bertrand Meyer, начало 90х. Чем больше методов — тем сильнее нарушается инкупсуляция.
30 лет как ООП совсем другое, пора бы познакомиться с новшествами

I>>С глубокой иерархией интерфейсов все ровно так же.
НС>Нет.

И никакого обоснования, как будто это и так ясно. Аргументы будут?

I>>Например, если в иерархии, построеной на иммутабельный принципах
НС>Иммутабельность никогда не была тем, что ОО контракты гарантируют.

Возьми любое другое свойство, например тот самый метод add. Нагородил некто глубокую иерархию, а потом взял да и сломал базовый интерфейс.

I>>А вот смысл конкретной абстрации вполне себе может быть в иммутабельности.
НС>При чем тут наследование и интерфейсы?

Тебе интерфейсы для чего нужны? Что именно ты решаешь этими интерфейсами? Приведи пример.

I>>Именно — не может. А раз не язык даёт гарантии, то кто их предоставит?
НС>Ну да, вернулись к "раз мы всех воров поймать не можем, то нефик их вообще ловить".

Всё проще фича extends это плохое решение, которое плохо решает три задачи — subtype, переиспользование и композицию. А нужны раздельные языковые конструкции для каждого аспекта.

НС>>>Ты пытаешься лишить меня выбора, зачем то навязывая мне потребности в гарантиях иммутабельности.
I>>Это просто пример.

НС>Нет, это не просто пример. Если выкинуть ммутабельность — в твоих аргументах и построениях вообще ничего не останется.

С методом add всё 1 в 1. Любое свойство ведет себя ровно так же, и иммутабельность ничем не лучше и не хуже других примеров.
Проблема в том, что нет внятного языкового способа выразить эти самые гарантии. Чтото есть в эйфеле, но он не летает в мейнстриме.

I>>Можем взять еще проще — как ты обеспечишь гарантии, что add добавляет в конец списка свой параметр и вытекающие свойства — длина увеличивается на единицу и тд.
НС>На уровне ОО контрактов? Очевидно никак.

Вот чудо — и тут интерфейсы облажались Почему же ты ждешь чего то большего от наследования?

НС>Нет, никакого решения проблоемы ты не показывал. Исключительно пытался показать, что ОО контракты не контролируют иммутабельность, хотя с этим никто и не спорил.

Я привел два примера. Например, очистка в add. Но ты еще видишь только второй пример, с иммутабельностью.

>Возражение тут вызывает то, что ты назначил отсутствие контроля иммутабельности главным недостатком наследования.

Ты игнорируешь аргумент про очистку add, делаешь вид, что речь была только про иммутебельность. То есть, то самое имаго