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

·>Ты продемонстрировал readonly-view. Иммутабельности тут нет. В С++ иммутабельности тоже нигде нет (в лучшем случае для примитивов). Есть только readonly.

У "неизменяемости" может быть сколько угодно синонимов и разных ключевых слов в разных ЯП — const, readonly, final и т.д.


·>Разберись чем отличается "неизменяемость" от "доступ только для чтения".

Всё-таки эзотерика? ))
Хорошо, что ты прилюдно признался.
В угол, на гречку!

Тебе уже говорилось, где у тебя каша в голове — надо рассуждать в терминах алгоримов над неизменяемыми данными, а не просто о самих таких данных.


·>Пример для совсем тупых: "/proc/uptime" — является read-only файлом. Он иммутабельный?

Это пример от тупых, ведь они понятия не имеют, как устроен этот файл.
Вполне может быть так, что на иммутабельных типах данных унутре, что почти всегда и происходит в тех же lock-free реализациях, когда ширина типа данных больше ширины слова — тогда значением оперируют по ссылке, которую (ссылку) подменяют в безблокировочной манере, но по самой ссылке находятся неизменяемые/иммутабельные данные.

Твой "/proc/uptime" — это может быть лишь интерфейсом к таким данным. ))

В любом случае, неизменяемость данных означает init-only характер оперирования данными, и как ты собрался "доказать", что это не так в случае "/proc/uptime"?
Опять поторопился и опять облажался?


·>Когда разберёшься, приходи.

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

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

1. Интерфейсы не имеют к иммутабельности никакого отношения, а служат для чего и придуманы в ООП — это ср-во абстрагирования для целей последующего обобщения.

2. Разница набора операций в IReadOnlyXXX и IImmutableXXX показывает лишь озвученную разницу — в уровне абстрагирования/обобщения, соотв. IReadOnlyXXX может быть использован в более общем коде, а IImmutableXXX в более специализированном. Плюс, не стоит забывать, что интерфейсы — это совокупность операций, представляющих собой "тип" в ООП-ЯП (см второй абзац этого поста).

3. Набор операций IReadOnlyXXX является подмножеством IImmutableXXX (ты даже с этим пытался спорить, не посмотрев на граф наследования), но оба интерфейса к иммутабельности не имеют никакого отношения, когда речь заходит о гарантиях. Бо интерфейсы (абстрактные классы) в классическом ООП используют не для гарантий, а как единственный доступный механизм построения и оперирования абстракциями. Остальное — спекуляции полуграмотных полупрограммистов из цикла "слышал звон".

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

5. Любые гарантии/ограничения, которые предоставляет ЯП для решения тех или иных классов задач, намного лучше отсутствия таких ср-в.

Весь этот спор — это просто тебя и еще одного громкого чела душила жаба, что в жабке нет адекватных ср-в для решения задач над иммутабельными типами данных (у второго дотнет чаще чешется). Вы тупо беситесь в попытках оправдать любимые ЯП, увлекаетесь и не проверяете свой бред на соответствие хотя бы определениям и здравому смыслу.

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

Поэтому, если бы ты хоть что-то понимал в таких алгоритмах, тебе достаточно было ткнуть в отсутствие GC в C++ и одновременно в происходящее во многих многих таких алгоритмов (например, алгоритмы над иммутабельными сбалансированными деревьями и вообще над иммутабельными версионными графами, известными еще со времён самого первого Лиспа), где наличие GC упрощает реализацию таких алгоритмов.

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

·>Ты продемонстрировал readonly-view. Иммутабельности тут нет. В С++ иммутабельности тоже нигде нет (в лучшем случае для примитивов). Есть только readonly.

У "неизменяемости" может быть сколько угодно синонимов и разных ключевых слов в разных ЯП — const, readonly, final и т.д.


·>Разберись чем отличается "неизменяемость" от "доступ только для чтения".

Всё-таки эзотерика? ))
Хорошо, что ты прилюдно признался.
В угол, на гречку!

Тебе уже говорилось, где у тебя каша в голове — надо рассуждать в терминах алгоримов над неизменяемыми данными, а не просто о самих таких данных.


·>Пример для совсем тупых: "/proc/uptime" — является read-only файлом. Он иммутабельный?

Это пример от тупых, ведь они понятия не имеют, как устроен этот файл.
Вполне может быть так, что на иммутабельных типах данных унутре, что почти всегда и происходит в тех же lock-free реализациях, когда ширина типа данных больше ширины слова — тогда значением оперируют по ссылке, которую (ссылку) подменяют в безблокировочной манере, но по самой ссылке находятся неизменяемые/иммутабельные данные.

Твой "/proc/uptime" — это может быть лишь интерфейсом к таким данным. ))

В любом случае, неизменяемость данных означает init-only характер оперирования данными, и как ты собрался "доказать", что это не так в случае "/proc/uptime"?
Опять поторопился и опять облажался?


·>Когда разберёшься, приходи.

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

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

1. Интерфейсы не имеют к иммутабельности никакого отношения, а служат для чего и придуманы в ООП — это ср-во абстрагирования для целей последующего обобщения.

2. Разница набора операций в IReadOnlyXXX и IImmutableXXX показывает лишь озвученную разницу — в уровне абстрагирования/обобщения, соотв. IReadOnlyXXX может быть использован в более общем коде, а IImmutableXXX в более специализированном. Плюс, не стоит забывать, что интерфейсы — это совокупность операций, представляющих собой "тип" в ООП-ЯП (см второй абзац этого поста).

3. Набор операций IReadOnlyXXX является подмножеством IImmutableXXX (ты даже с этим пытался спорить, не посмотрев на граф наследования), но оба интерфейса к иммутабельности не имеют никакого отношения, когда речь заходит о гарантиях. Бо интерфейсы (абстрактные классы) в классическом ООП используют не для гарантий, а как единственный доступный механизм построения и оперирования абстракциями. Остальное — спекуляции полуграмотных полупрограммистов из цикла "слышал звон".

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

5. Любые гарантии/ограничения, которые предоставляет ЯП для решения тех или иных классов задач, намного лучше отсутствия таких ср-в.

Весь этот спор — это просто тебя и еще одного громкого чела душила жаба, что в жабке нет адекватных ср-в для решения задач над иммутабельными типами данных (у второго дотнет чаще чешется). Вы тупо беситесь в попытках оправдать любимые ЯП, увлекаетесь и не проверяете свой бред на соответствие хотя бы определениям и здравому смыслу.

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

Поэтому, если бы ты хоть что-то понимал в таких алгоритмах, тебе достаточно было ткнуть в отсутствие GC в C++ и одновременно в происходящее во многих таких алгоритмах (например, алгоритмы над иммутабельными сбалансированными деревьями и вообще над иммутабельными версионными графами, известными еще со времён самого первого Лиспа), где наличие GC упрощает реализацию таких алгоритмов.