Юра
Но наверное такой ситуации не должно возникать по фен-шую
Dmitry
Юра
А вы такое знали?
$this->someProp?->someMethod()
Юра
наплодили операторов блин )
Алексей
у котлина давно такое
Алексей
удобно чем ифами баловаться
The Ant
Короче вопрос в том как обновить все иммутабельные объекты
Через мап новые создать же. В редаксе такой хуйней пару лет побаловались, и выкинули этот редакс на помойку истории
The Ant
Про тотальную иммутабельность в целом мечтать хорошо. На практике это какой-то буллшит с кучей проблем
Konstantin
А вы такое знали?
$this->someProp?->someMethod()
ещё вот так можно, раз за новые операторы речь зашла
$this->foo ??= $this->initHeavyDep();
Vlad
не знаю никаких проблем с иммутабл
Konstantin
производительность, повышенная нагрузка на гц, но в пхп это важно в меньшей степени
Vlad
в одном проекте все иммутабельно, кроме сущностей естественно
Konstantin
а так да
Vlad
производительность, повышенная нагрузка на гц, но в пхп это важно в меньшей степени
тут как бе я не уверен, что нагрузка на гц есть. к примеру в го эффетивнее работать с клонироваными структурами. мб что пхп что подобное есть, надо смотреть сорцы
The Ant
не знаю никаких проблем с иммутабл
Если их нет, с чего тогда вой стоит от связки реакт+редакс?
The Ant
в одном проекте все иммутабельно, кроме сущностей естественно
Ну вот у тебя есть коллекция иммутабельных дтошек. В ней у 1 объекта надо изменить одно поле. Что делать?
Vlad
да даже если есть нагрузка на гц, это скока надо иметь рпс, чтобы об этом задумываться? дай бог будет 1к rps это не проблема
Vlad
Ну вот у тебя есть коллекция иммутабельных дтошек. В ней у 1 объекта надо изменить одно поле. Что делать?
foreach + clone или new если используешь реадонли
The Ant
Тут вручную гонять эти сраные иммутабельных объекты устанешь. Особенно когда надо работать с коллекциями. Фильтровать, изменять
The Ant
foreach + clone или new если используешь реадонли
Сама коллекция тоже должна быть иммутабельной?
Vlad
ну если коллекция тока для чтения то иммутабл
Юра
Не знаю я с имутабельностю постоянно натыкаюсь на костыли
Юра
Пример
Юра
Правда было это во флатере
Юра
Рисовал список там чего-то. Все было сделано по фен-шую мать его имутабл
Юра
Прилетал имутабл стейт имутабл айтемов списка
Юра
Все супер
Юра
И тут тебе говорят надо сделать анимацию добавления удаления айтемов
Юра
И все
Юра
Весь имутабл летит к чертям
Юра
Потому что виджет анимации работает через addItem removeItem
Юра
В итоге начал городить сравнение списков и генерацию дифа
Юра
Потом понял каким же бредом я занимаюсь и переделал на мутабл
Юра
Никаких лишних списков, все максимально эффективно
Юра
Чего
Павел
Чего
Что, "чего"? Не понял . Имею ввиду что список (ну или его стейт, хотя не совсем понял что такое стейт списка) как иммутабельный объект - звучит бредово, ну имхо конечно
Юра
Да так же звучит как имутабл дто
Юра
Если твой дто имутабл и внутри у него мутабл лист, то это не имутабл дто
Юра
В пхп кстати readonly array
Юра
Запрещает модификацию массива
Павел
Имутабл список - звучит как то бредово)
Хотя с другой стороны, если список изменили, возможно это уже другой список и есть смысл в иммутебельности. Сложна...
Юра
Тогда ты делаешь dto.withList(oldList.push(val))
Юра
Ну псевдокод
Юра
И получаешь новую дто с новым имутабл листом)
Юра
Ну пуш он типа возвращает новый лист
Павел
Ну кстати с дто был кейс, где я изза мутатаблеьности баг словил. Для простоты изменил значение, а вдругом месте не нужно было это изменение, а нужно было первоначальное)
Хотя тут вообще тема хорошого кода, что не менять входные параметры
Юра
Хаскель говорят крутой
Юра
Все имутабл, в компайл тайме все чеуается
Юра
Таких тупых багов там сложно наделать
The Ant
Юра
Но чёт он не особо популярен
Павел
Как в пхп можно баг такой словить? Он же однопоточный
Банально из-за своей тупости)
Удобно было почему то (не помню почему), сделать $data->param+=$a, а не $newVar = $data->param+$a; А далее забыл что изменил )
Павел
Как в пхп можно баг такой словить? Он же однопоточный
Ну а если тему про стейтфул поднять, то можно словить всякие шляпы в всяких родраннерах, и мессенджерах - если специально не сбрасывать. Хотя это разные кейсы
The Ant
Ну а если тему про стейтфул поднять, то можно словить всякие шляпы в всяких родраннерах, и мессенджерах - если специально не сбрасывать. Хотя это разные кейсы
стейтфул в вебе такое себе, особенно если надо скейлить по нескольким физическим серверам. Оптимально на мой взгляд делать стейтлесс сервисы и гонять реквест как контекст. Которые убивается после обработки реквеста. А редко изменяемые штуки кешировать гденить. Или в памяти, или в редисе каком.
Короче говоря, твоя приложуха это прокси для данных от юзера в базу. Если не пытаться сделать гибрид какой, то за потоком данных достаточно легко будет следить.
Konstantin
не везде это можно сделать (говорю как человек, который тоже топит за стейтлесс везде, но у которого основной стек в компании - это джава). условно говоря, вызов локального кеша - это максимум 0,01мс, вызов кеша в редисе - 10мс. уже на миллионе запросов в кеш, делать стейтлесс нереально. на самом деле, таких задач довольно много, когда надо что-то большое, и зависящее от сотен параметров посчитать, и потом отдавать на запрос
Konstantin
из простых примеров - база geoip (это не совсем к делу относится, но порядок величин может показать), если её унести из локального mmdb в редис - будет жопа на ровно месте
The Ant
ну редис это просто как пример разделяемой памяти между несколькими физическими серверами.
Такие базы как геоип очень редко обновляются, поэтому можно не шарить её, а полодить локально на каждый сервер.
Konstantin
я понимаю, да, что редис пример, я тоже не про конкретный редис, а про distributed memory
The Ant
Речь скорее о том, что на 2+ серверах у стейтфулл приложухи придется решить проблему синхронизации этого стейта
Konstantin
то есть джаву (как и остальной стейтфул) берут не от нехер делать и не от хорошей жизни, часто просто нереально закешировать структуру данных, зависящих от сотен входных параметров для 30 лямов юзеров. рекомендации какие, например, только считать и хранить в памяти подгтотовленные модели и каждый раз пересчитывать
Konstantin
я тоже всегда с джавистами воюю на этот счёт, что задолбали ваши стейтфул сервисы, которые вечно то оомятся, то стартуют пять минут, то "ЭТОТ НИ В КОЕМ СЛУЧАЕ ДУБЛИРОВАТЬ НЕЛЬЗЯ, СТРОГО ОДИН ИНСТАНС!1111". если тебе интересно, могу попросить накидать мне пяток примеров для чисто веб-задачек, где без этого никак
Konstantin
но да, пока можете делать стейтлесс - делайте стейтлесс, это драматически проще
The Ant
та не над ) я не топлю радикально же. Время доступа к данным иногда имеет критическое значение. И блин... ну некоторые даже на мейнфреймах сидят, чтобы прям вот наносекунды экономить 😄
Konstantin
на мейнфреймах, мне кажется, сидят не ради экономии (они сами по себе не сильно быстрые), а просто когда люди не в состоянии распилить монолит по мере увеличения нагрузки/датасета и просто закидывают железом
Konstantin
ну типа будет у нас хип в джаве 5 тб
Konstantin
зато делать с кодом ничего не нужно! банки примерно так и мыслят, нахера переписывать опердень из 80х, три года кодить, результат негарантирован, масса проблем, а тут просто купил железку у вендора и всё работает
Konstantin
а те, кто наносекунды экономят (сейчас это в основном алгоритмический трейдинг), там уже скорее не мейнфреймы, а всякие специализированные под задачу железки - асики всякие, и вот это всё
The Ant
Хз, сложно тут что-то говорить. Из того что я вычитал, данные очень близко друг к другу и к обработчикам находятся.
В микросервисах всё-таки сетевой стек станет бутылочным горлышком на серьезных объемах вичислений и транзакций между серверами.
Павел
стейтфул в вебе такое себе, особенно если надо скейлить по нескольким физическим серверам. Оптимально на мой взгляд делать стейтлесс сервисы и гонять реквест как контекст. Которые убивается после обработки реквеста. А редко изменяемые штуки кешировать гденить. Или в памяти, или в редисе каком.
Короче говоря, твоя приложуха это прокси для данных от юзера в базу. Если не пытаться сделать гибрид какой, то за потоком данных достаточно легко будет следить.
Да это понятно, но вот бывают всякие штуки, которые ну прям хочется сделать стейтфул.
У нас например сейчас это ивент коллектор. Чтобы не делать outbox, но при это ивенты отправлять только после закрытой транзакции - собираем в сервис, который вызывается в разных частях. Возможно можно сделать как то почетче, но чет пока не придумали. Ну и такая архитектура развалится в каком нить роадраннере, из-за стейтфула.
The Ant
Да это понятно, но вот бывают всякие штуки, которые ну прям хочется сделать стейтфул.
У нас например сейчас это ивент коллектор. Чтобы не делать outbox, но при это ивенты отправлять только после закрытой транзакции - собираем в сервис, который вызывается в разных частях. Возможно можно сделать как то почетче, но чет пока не придумали. Ну и такая архитектура развалится в каком нить роадраннере, из-за стейтфула.
что мешает создавать новый ивент коллектор на каждую транзакцию?
The Ant
это ж просто массив
Павел
что мешает создавать новый ивент коллектор на каждую транзакцию?
transaction(){
action();
action();
}
collector->release()
Можно конечно передавать в action, но проблема в том, что они из di, т.е. надо выходит просовывть в хэдлер через сеттер, или как аргумент метода
Павел
ну или еще какие варианты, но все это будет болерплйетом покрыто тогда
The Ant
Павел
фабрику этого коллектора доставать с контейнера? )
Что это даст? Проблема не в том, что коллектор из di, а что надо единый коллектор перемещать через все экшены в которых он участвует
Павел
И сохранять состояние
The Ant
Даст возможность создавать локальный коллектор и не держать его в контейнере со стейтом