Это обязательное условие для выполнения иммутабильности.
Нет, не обязательное. Просто, читая "Объект не может быть изменён. Если нужно новое состояние, создаётся новый объект, исходный остаётся неизменным", вы упёрлись в единственную трактовку, что "не может" означает якобы техническую невозможность ("должно быть невозможно поменять"), и не допускаете, что это может быть нормативным требованием "не надо менять".
Structural sharing не меняет старый объект, и он создаёт новый объект на основе старого. Если вы сами злонамеренно не меняете старый объект, то все условия иммутабельности выполнены.
Глубокое клонирование точно так же никак не защищает старый объект от злонамеренного изменения, какой-нибудь уникум всегда может написать:
-- и всё, приехали. Тогда каким образом structuralClone является "настоящей иммутабельностью", по-вашему?
Иммутабельность -- это в первую очередь дисциплина, принцип, паттерн. Если есть дополнительные safeguards через средства языка (вроде Object.freeze или opt-in mutability как в Расте) или через библиотеки типа ImmutableJS -- отлично, но если нет, то вы всё равно можете использовать её, просто избегая прямых мутаций состояния.
Про tradeoff "производительность vs фишки"я в четвёртый раз одно и то же писать не буду, если с трёх раз не дошло, то я пас.
Как бы да, копирование ПОЛНОЕ) Иначе вы иммутабильность путаете с мутабильностью. Если копирование не полное, то вы НАРУШАЕТЕ иммутабильность, они больше иммутабильностью не является.
Похоже, у вас понятие "полное" какое-то совершенно отличное от моего. Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Structural sharing не клонирует всех детей до последнего колена -- те объекты, что не поменялись, остаются на месте, их никто не удаляет, они шарятся между обоими копиями стейта (и при хорошем дизайне это бОльшая часть стейта). Никакого нарушения иммутабельности при этом нет, хотя клонирование тут частичное (в том смысле, что не для всех данных производятся дубликаты).
Чушь несете вы, не понимая принципов работы процессора, материнской платы и оперативной памяти.
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
И уж тем более не понимаете принципе иммутабильнсти.
Судя по тому, что вы называете structuredClone "настоящей иммутабельностью", принципов не понимаете вы. Я даже не знаю откуда вы эту чушь берёте, клонирование и иммутабельность -- это концептуально разные вещи, хоть и идут рука об руку рядом. Может быть клонирование без иммутабельности, может быть иммутабельность без клонирования (любая константа вам скажет)
Вот вам, бенчмарк
Если у вас весь стейт -- это один огромный плоский массив/мапа на тысячи элементов, то да, будут проблемы с производительностью, потому что основными затратами будет перекладывание одних и тех же ссылок. Да, такие структуры плохо подходят для immutability, если стейт надо часто менять, кто бы спорил. И никто не спорит, что лазить в структуры напрямую и "пачкать" данные "по-живому" эффективнее с т.з. скорости. Ну так горе-админы тоже считают, что лазить на прод и что-то там менять напрямую -- это быстрее и эффективнее. До первого падения прода и люлей.
Иммутабельность имеет свою цену -- я это могу вам повторить ещё раз, если первые два раза не поняли. Точно так же, как запрет лазить на прод руками имеет свою цену. Вопрос в том, готовы ли вы платить эту цену за отсутствие головняка с гонками данных, неконсистентностью, откатами и прочими ништяками.
Если у вас стейт -- не огромный плоский массив, а более-менее глубокое дерево, то выигрыш прямый изменений уже становится не такой уж значительный:
Что именно вы разоблачили? На ваши комменты c разоблачениями были ответы, простое повторение тех же комментов не является разоблачением, заявы "Ппц, на полном серьезе такую брехню нести" ими тоже не являются -- я тоже умею такие заявы кидать.
Я вижу вы ярый апологет MobX. Я ничего против MobX не имею, я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука, которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих. Это просто чушь, выкурите structural sharing уже.
Ну и, к слову о розовых очках и реальности: тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных. "С каких это пор постоянный копирование объектов трекинг зависимостей на каждый чих это оптимизация?" (с) алаверды
Т.е. проблема аллокаций просто перемещается на другой уровень. То, что в вашем коде их нет, не значит, что их нет вообще. "А может ещё это бесплатно и память не кушает?)))" (с) алаверды-2
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Класс, рекурсивный обход 2х объектов и сравнение полей)
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
У MobX есть такая штука
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
вы путаетесь в показаниях и включаете заднюю
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
есть такие штуки getters/setters ... Было изменение, вызывает реакции
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Да вы что, прям яваскрипт знает какая часть неизменной будет, а какая нет?)))
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Каждая манипуляция стоит времени, места и энергии.
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
ПДД — гарантирует безопасное передвижение по дорогам общего пользования, в случае когда пользователи этих самых дорог САМИ же их и исполняют!
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
У меня цель— прогрессивное развитие нашей Цивилизации.
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Я предлагаю— хорошенчеко сесть т подумать над всем комплексом.
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
самолетная отрасль полетов — полностью зарегулирована.
Иммутабельность даёт гарантии, что объект, который ты получил, не взорвётся у тебя в руках останется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флагов isModified, или перерисовывать весь UI на каждый чих.
Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
С каких пор полное копирование участка памяти(объекта) с целью его изменения
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.
В общем, жить можно вроде.
Нет, не обязательное. Просто, читая "Объект не может быть изменён. Если нужно новое состояние, создаётся новый объект, исходный остаётся неизменным", вы упёрлись в единственную трактовку, что "не может" означает якобы техническую невозможность ("должно быть невозможно поменять"), и не допускаете, что это может быть нормативным требованием "не надо менять".
Structural sharing не меняет старый объект, и он создаёт новый объект на основе старого. Если вы сами злонамеренно не меняете старый объект, то все условия иммутабельности выполнены.
Глубокое клонирование точно так же никак не защищает старый объект от злонамеренного изменения, какой-нибудь уникум всегда может написать:
-- и всё, приехали. Тогда каким образом
structuralCloneявляется "настоящей иммутабельностью", по-вашему?Иммутабельность -- это в первую очередь дисциплина, принцип, паттерн. Если есть дополнительные safeguards через средства языка (вроде
Object.freezeили opt-in mutability как в Расте) или через библиотеки типаImmutableJS-- отлично, но если нет, то вы всё равно можете использовать её, просто избегая прямых мутаций состояния.Про tradeoff "производительность vs фишки"я в четвёртый раз одно и то же писать не буду, если с трёх раз не дошло, то я пас.
Похоже, у вас понятие "полное" какое-то совершенно отличное от моего. Для меня полное копирование -- это глубокое клонирование, т.е. создание полного клона объекта, с клонированием всех полей, включая детей, и внуков, правнуков и т.д.
Structural sharing не клонирует всех детей до последнего колена -- те объекты, что не поменялись, остаются на месте, их никто не удаляет, они шарятся между обоими копиями стейта (и при хорошем дизайне это бОльшая часть стейта). Никакого нарушения иммутабельности при этом нет, хотя клонирование тут частичное (в том смысле, что не для всех данных производятся дубликаты).
Умерьте пыл, телепат вы наш, есть немалый шанс, что принципы процессора и проч я изучил, когда вы ещё под стол пешком ходили.
Судя по тому, что вы называете
structuredClone"настоящей иммутабельностью", принципов не понимаете вы. Я даже не знаю откуда вы эту чушь берёте, клонирование и иммутабельность -- это концептуально разные вещи, хоть и идут рука об руку рядом. Может быть клонирование без иммутабельности, может быть иммутабельность без клонирования (любая константа вам скажет)Если у вас весь стейт -- это один огромный плоский массив/мапа на тысячи элементов, то да, будут проблемы с производительностью, потому что основными затратами будет перекладывание одних и тех же ссылок. Да, такие структуры плохо подходят для immutability, если стейт надо часто менять, кто бы спорил. И никто не спорит, что лазить в структуры напрямую и "пачкать" данные "по-живому" эффективнее с т.з. скорости. Ну так горе-админы тоже считают, что лазить на прод и что-то там менять напрямую -- это быстрее и эффективнее. До первого падения прода и люлей.
Иммутабельность имеет свою цену -- я это могу вам повторить ещё раз, если первые два раза не поняли. Точно так же, как запрет лазить на прод руками имеет свою цену. Вопрос в том, готовы ли вы платить эту цену за отсутствие головняка с гонками данных, неконсистентностью, откатами и прочими ништяками.
Если у вас стейт -- не огромный плоский массив, а более-менее глубокое дерево, то выигрыш прямый изменений уже становится не такой уж значительный:
https://stackblitz.com/edit/stackblitz-starters-c2hsjkty?file=src%2Findex.tsx
Особенно если программист не идиот и не складывает быстро-меняющиеся данные в общий стейт.
Что именно вы разоблачили? На ваши комменты c разоблачениями были ответы, простое повторение тех же комментов не является разоблачением, заявы "Ппц, на полном серьезе такую брехню нести" ими тоже не являются -- я тоже умею такие заявы кидать.
Я вижу вы ярый апологет MobX. Я ничего против MobX не имею, я спорю только с вашим аргументом, что иммутабельность -- супердорогая штука, которая якобы приводит к ПОЛНОМУ копированию всего состояния на каждый чих. Это просто чушь, выкурите structural sharing уже.
Ну и, к слову о розовых очках и реальности: тот же MobX под капотом приводит к аллокациям и диффам на каждый пересчёт каждого derivation, с целью отслеживания [новых] зависимостей, с дедупликацией оных. "С каких это пор постоянный
копирование объектовтрекинг зависимостей на каждый чих это оптимизация?" (с) алавердыТ.е. проблема аллокаций просто перемещается на другой уровень. То, что в вашем коде их нет, не значит, что их нет вообще. "А может ещё это бесплатно и память не кушает?)))" (с) алаверды-2
Возвращайтесь, я не против.
Конкретных разоблачений "брехни", конечно же, не дождёмся.
https://mol.hyoo.ru/ -- английской документации, как я понимаю, нет -- индикатор языка слева внизу показывает "English", но вся документация, кроме меню -- на русском. Переключение языка переключает только язык навигации. Ну да ладно, в гитхабе доки есть, это не глюк, а ограничение целевой аудитории.
https://page.hyoo.ru/#!=6leyma_5ks814 -- примеры втиснуты в милипиздрические фреймы, на экране лаптопа превращающиеся в горизонтально-скроллируемые бронещели танка; зато куча экранной ширины щедро отдана под бесполезную и неубираемую/неизменяемую панель закладок и боковые поля
При всём этом аттракционе щедрости, весьма полезный вертикальный скроллбар тоже миллипиздрический, словно от сердца оторванный. И если зажать ползунок и потащить его мышкой, то мышка отрывается от ползунка, и тот скроллится со своей скоростью. Да, я помню ваш аргумент, что это ограничение виртуального скроллинга, где размеры элементов заранее не известны и параметры скроллера вычисляется динамически -- вот только то же самое случается на коротких статических страницах где виртуальный скроллинг не нужен, и нет динамически подгружаемого контента. Но у вас он впихнут везде, как я понимаю. Поэтому выходит, что скроллер прыгает даже на жалких 2-3-х экранах статического текста: https://page.hyoo.ru/#!=3498sy_ioyx6t . Можно очень много, долго и убедительно рассказывать про борьбу за производительность, но видя такое хочется закрыть вкладку и забыть немедленно, потому что возникает впечатление, эта это борьба ради борьбы (впрочем, это почти про все фреймворки можно сказать).
Даже если проблему пересчёта не обойти, почему бы не сделать изменение размера скроллера более незаметным, через плавное изменение высоты, например?
Это только то, что бросилось в глаза за первые 5 минут чтения.
Этот прокси а) опциональный "сахар", б) создаётся на стороне писателя (которых мало), в) создаётся на короткое время, пока правится "черновик" изменений, а не висит постоянно в сторе (движок может оптимизировать это через escape anaysis и аллокации на стеке или в nursery).
После создания объекта с измениями он (объект) остаётся простым иммутабельным POJO до самого уничтожения.
Вы уже предлагаете
учить новый непопулярный синтаксис с жёсткими правилами на форматирование и невидимые символы (табы, переносы строк и проч),
тащить в проект кодогенерацию (бррр),
тащить в проект непопулярный билдер с неясными проблемами совместимости с либами,
и проч
-- т.е. повышаете уровень входа до уровня ангуляра. Это значит, что мелкие проекты не возьмут ваш фреймворк практически никогда -- слишком много возни. А крупные проекты не возьмут ваш фреймворк вообще никогда -- из-за рисков, глючной документации с плохим/отсутствующим/нерабочим английским, attitude issues и т.п.
Но вы продолжайте считать несогласных говноедами, а ваш фрейморк самым правильным, это так успокаивает.
Или Immer, например.
Но, вообще говоря, писатель обычно не просто так меняет данные, и вероятность, что он постоянно меняет данные на точно такие же, мала.
Я, вообще-то, спрашивал про голые JS проперти, без того чтобы вместо POJO втаскивать прокси на каждый объект в сторе и на его собаку, развесистый реактивный граф коллбэков (и системой, поощряющей делать его как можно развесистей), c потенциалом налететь на утечки, циклические зависимости и бесконечный цикл, N+1, чувствительность к порядку апдейтов, который мы не выбираем явно. Проблем, конечно, можно избежать -- но вы же требуете полной беззаботности со стороны девов, а сами её предложить не можете.
А ещё боремся за почетное звание «Дома высокой культуры и быта!» (с)
Правда в том, что борясь за одно, приходится жертвовать другим.
Или у вас есть фантазия, что вы будто бы прокурор, а я будто бы даю вам какие-то показания.
Я с первого коммента сказал, что иммутабельность -- не панацея, и что для получения гарантий нужна дисциплина со стороны писателя. Вы же, судя по вашей бурной реакции, почему-то предположили, что я топлю за иммутабельность как за серебрянную пулю и отчаянно бьюсь с вами.
Представляете, есть люди, которые занимаются разными вещами в разное время, и как-то время им чем-то приходится не пользоваться. Поэтому скорость забывания значение имеет.
Есть разные вещи, про которые я читал, но не пробовал (всего не перепробуешь), но степень их забывания почему-то разная.
Признаться, после чтения статей про атомы и проч я был заинтригован, и тайпскриптная часть была интересной. Поэтому я потратил некоторое время на изучение документации. Оно вроде как и не сильно сложно, но нет, мне не показалось очень мнемоничным. Т.е. когда читаешь доку, вроде понятна идея. Но, вернувшись через некоторое время, я понял, что практически ничего не запомнилось, и трудно по памяти восстановить, какая именно идея стояла за определённым синтаксисом. Т.е. ход "идея --> синтаксис" работает, а обратный ход "синтаксис --> идея" -- не очень.
У меня не сильно хорошая память, я, например, и вимом не пользуюсь поэтому -- слишком много клавиатурных жестов запоминать, потом мучительно вспоминать после пауз. Вдобавок, я фронтендом занимаюсь лишь эпизодически, поэтому паузы длинные. Так что я решил, что это не моя чашка чая. И, подозреваю, так решили многие (если не все).
ЗЫ. Я так же не люблю snake_case и yaml, и с большой неохотой пользуюсь всякими декораторами, атрибутами и проч, так как они создают паралельный язык, которым легко злоупотреблять (привет, ангуляр), получить проблемы с рефакторингом и проч. Но это личные загоны.
Это ответственность того, кто меняет данные. Обычно писателей мало, читателей много, поэтому забота о том, чтобы не создавать ложных псевдо-изменений ложится на писателей. Да, нужна определённая дисциплина -- либо библиотека, берущая это на себя.
Сделайте с сеттерами пачку из 100 изменений, вызвав эффект лишь один раз по окончании пачки. Например, в массиве 100 объектов нужно выставить у каждого "active = false" и не триггернуть 100 последовательных перерисовок. И, при этом желательно не делать 100 подписок на событие "onActiveChanged".
Тот, кто меняет -- знает, и должен соблюдать правило: "нет реальных изменений -- ничего не меняй"
Именно поэтому нужно избегать манипуляций, когда они не нужны. А не нужны они там, где ничего не поменялось. А чтобы в сложном композитном объекте эффективно определить, где именно ничего не поменялось, нужна иммутабельность, при которой проверка сводится к сравнению пары указателей, а не к обходу всего дерева состояний в поисках изменений.
У вас в эмбеде наверное нету развесистых деревьев состояний и их презентаций, как в пользовательском UI, вот вам и не нужно это всё. Вы с другой колокольни смотрите.
Оно читаемое -- сразу после момента когда прочитал документацию. Но через некоторое время, после работы с другими вещами, которые занимали мозг, большая часть знаний это птичьего языка улетучивается, и без заглядывания в доки опять ничего не понятно.
Да прямо завтра и начну. В самом-то деле, 35 лет код пишу, куда уже дальше откладывать?
Если хз, то подскажу более подходящий термин. и, соответственно, название склонности.
Take care.
LOL ещё 3 раза. Я ещё помню времена, когда в ПДД до недавнего времени не было даже определённости, что называть "обгоном", и до сих пор имеются неоднозначные формулировки, которые можно интерпретировать по-разному. И это только ПДД РФ, в то время как в мире имеются ПДД других стран.
Плюс имеются best practices, не прописанные в ПДД, и даже есть рекомендации плохих практик (например, рекомендация перестраиваться заранее перед сужением вместо "zip merge", что приводит к растягиванию пробок).
Поздравляю, вы один такой белый рыцарь, все остальные -- жадные ублюдки, после которых хоть потоп. /s
Что конкретного Вы уже сделали для достижения этой цели, кроме уговаривания других?
Ваш снисходительный совет специалистам "хорошенечко сесть, подумать и написать директивы" является настолько же бесполезным, насколько бесплатным. Проблема не в отсутствии статей и рекоменаций -- их написано тонны. Проблема в том, что панацей, серебрянных пуль и универсальных парадигм с гарантией успеха, не существует, как бы вам не хотелось.
Вы ошибаетесь насчёт "полностью".
Иммутабельность даёт гарантии, что объект, который ты получил, не
взорвётся у тебя в рукахостанется тем же всегда, и тебе не надо кропотливо и пристально следить, не поменялось ли что-то в его нутрях, или втыкать и таскать повсюду кучу флаговisModified, или перерисовывать весь UI на каждый чих.Иммутабельность предоставляет простой способ детектирования наличия изменений: если ссылка на объект не поменялась, значит 100% изменений в нём нет, можно пропустить всю работу по проверке и обновлению данных и UI.
Полного копирования при изменениях не происходит -- для неизменённых частей копируются только ссылки верхнего уровня.
Как у любого решения, у этого есть своя цена, каждый сам должен решать, что выгоднее в его конкретном случае.
При правильном подходе новый объект создаётся не полным копированием всех данных, а путём копирования ссылок на неизменённые данные, плюс новые примитивы/ссылки в местах изменений. Т.е. копирование происходит только для части ссылок и части примитивов, но это достаточно дёшево, так как для них есть быстрые кучи/арены. Когда вы меняете строку "по месту", у вас точно так же есть шанс получить либо перераспределение памяти, либо её недоиспользование, поэтому строки в современных managed языках сплошь immutable, ибо так на круг выходит дешевле.