Сообщение Re[94]: Когда это наконец станет defined behavior? от 20.02.2024 11:31
Изменено 20.02.2024 11:34 vdimas
Re[94]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
·>Ты продемонстрировал 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 упрощает реализацию таких алгоритмов.
Re[94]: Когда это наконец станет defined behavior?
Здравствуйте, ·, Вы писали:
·>Ты продемонстрировал 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 упрощает реализацию таких алгоритмов.