вместо этого админ создаёт нового пользователя с другим паролем

как то ну не очень правильно звучит

ну конечно если я правильно понимаю

ты путаешь бд и код

админу надо поменять пароль пользователю

Это уже кейс завязанный на бд. Хотя есть имутабельные бд

ну код работает с памятью, а хранится всё в бд

в коде просто отображение данных из бд

типа не особо же важно с какой ячейкой памяти он работает в подобных задачах, разве нет?

вместо этого админ создаёт нового пользователя с другим паролем

Ты можешь делать изменения как это делается в гите, например

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

как ячейки памяти с бд связаны?)

Вот с бд ты так же можешь

Ты можешь делать изменения как это делается в гите, например

но зачем мне хранить все предыдущие версии пользователя?

опять - ты бд с кодом путаешь

но зачем мне хранить все предыдущие версии пользователя?

Да много кейсов есть когда это надо: Лог Тебе надо уметь возвращать состояния или как-то с ними работать

как ячейки памяти с бд связаны?)

ну типа вот мы в коде взяли данные из бд, они хранятся теперь в ячейке памяти, разве нет? поменяли там чё как надо, сохранили обратно

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

ну типа вот мы в коде взяли данные из бд, они хранятся теперь в ячейке памяти, разве нет? поменяли там чё как надо, сохранили обратно

можно менять в бд, не меняя ячейку памяти

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

ну и зачем мусорить память?

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

можно менять в бд, не меняя ячейку памяти

не уверен что понял тебя

почему ты её мусоришь? есть GC, если нет GC есть алгоритмы для очистки памяти

ну типа вот как в рельсах

взяли пользователся, храним в @user

поработали с ним как надо поменяли чё захотели

@user.save

ну вот чел тут утверждает что связные и даже обязательные и что по другому если то у тебя неправильное ооп

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

вот не совсем тоже понимаю почему таки иммутабельность это так круто

я вот только не пойму откуда у чувака 15к фоловеров…видимо надо ходить и вбрасывать “всё плохо”, что бы люди обращали на тебя внимание)

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

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

@user.save

тут просто рельса сохраняет пользователя в @user а могла бы к примеру возвращать новый инстанс юзера, а старый оставлять тем же

я вот только не пойму откуда у чувака 15к фоловеров…видимо надо ходить и вбрасывать “всё плохо”, что бы люди обращали на тебя внимание)

книги пишет вроде

вот не совсем тоже понимаю почему таки иммутабельность это так круто

можно палеллить ?

ну и зачем мусорить память?

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

тут просто рельса сохраняет пользователя в @user а могла бы к примеру возвращать новый инстанс юзера, а старый оставлять тем же

и зачем возвращать новый если можно сохранит ьуже этот?

ну разве очевиднее когда в update вызывается new?

вот не совсем тоже понимаю почему таки иммутабельность это так круто

Вместо внутреннего изменения стейта объекта ты создаёшь новый с новым стейтом. Это позволяет избежать запутанности логики и все поведение становится более линейным

и зачем возвращать новый если можно сохранит ьуже этот?

затем что ты явно берёшь измененого юзера и работаешь с ним

не уверен что понял тебя

a = Repository::Email.new.find_by_id() Repository::Email.new.update() b = Repository::Email.new.find_by_id() у a и b будут разные значения

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

Последний пункт мимо. Можно и с имутабельностью говно писать

a = Repository::Email.new.find_by_id() Repository::Email.new.update() b = Repository::Email.new.find_by_id() у a и b будут разные значения

ну они же всё равно уже в памяти будут

например смори у тебя есть юзер, ты знаешь что его др изменилось, сохрнаяешь юзера и после сохранения, если др валидно и сохранилось ты пишешь в лог изменение

взяли пользователся, храним в @user

ну там ты рассматриваешь чисто активрекорд, который не очень

ну они же всё равно уже в памяти будут

и в чем проблема?

в случае иммутабельность у тебя юзер - неизменный объект и ты точно уверен что он это твои входные данне

потом почистятся

и в чем проблема?

я подумал что у тебя изначальный тезис был "можно менять не подгружая в память"

Последний пункт мимо. Можно и с имутабельностью говно писать

Можно, но с таким ограничением у нас на одну возможность писать говно меньше

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

я подумал что у тебя изначальный тезис был "можно менять не подгружая в память"

ну ты вместо изменения создаешь новый объект

вот не совсем тоже понимаю почему таки иммутабельность это так круто

Супер пример: a = 1 test(a) a # => ?

Что в а будет?

ну ты вместо изменения создаешь новый объект

but why why would i do that

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

Ресурсов - ну кажется если это не микроконтроллеры то это не прям проблема. А вот оптимизация это да

Что в а будет?

зависит от test

иммутабельность - крутая шняга, но я бы не стал за неё сильно переживать

именно

с иммутабельностью у тебя не зависит

хм

Ресурсов - ну кажется если это не микроконтроллеры то это не прям проблема. А вот оптимизация это да

Да не, тоже проблемно, особенно когда надо про микроконтроллеры думать

but why why would i do that

так тебе только что объясняли

но ведь можно писать код (на руби) не мутируя переменные ?

за всё время я столкнулся может пару раз от силы с проблемами, когда что-то неожидано мутировалось

зависит от test

Это неопределенность, а с имутабельностью, ты точно знаешь, что а будет 1

ну ессно что много от прогера зависит

а это как то конкретно структурой языка достигается или чисто догооворённостью писать методы не мутирующие входной объект?

ну с иммутабельностью, судя по примерам которые я видал в разы проще тестить

ну с иммутабельностью, судя по примерам которые я видал в разы проще тестить

это 1000%

а это как то конкретно структурой языка достигается или чисто догооворённостью писать методы не мутирующие входной объект?

В некоторых языках ошибка выкидывается при попытке переписать переменную, в некоторых - договоренность

а это как то конкретно структурой языка достигается или чисто догооворённостью писать методы не мутирующие входной объект?

в руби - договоренностью или либами

в руби да, удобно что ! методы есть

ну с иммутабельностью, судя по примерам которые я видал в разы проще тестить

Это потому что уходит глобальный стейт и без него все становится в разы проще тестировать

но почему же тогда самые популярные языки мира все ооп)

я туповат на счёт стейта шмейта, по мне удобно что ты просто вход выход тестишь

в хаскелле - ошибку кинет

без моков хуёков

но почему же тогда самые популярные языки мира все ооп)

например?

Особенно легко понять почему «имутабельность» лучше. Достаточно посмотреть на то, как тестируется либы с глобальным конфигом и с конфигом на уровне инициализации

в хаскелле - ошибку кинет

В Эрланген так же и во всяких мл

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

ООП это не про языки :(

например?

это ты попробуй приведи пример фп языка популярного))

В чем критерий популярности?

define популярный

В чем критерий популярности?

ой всё

хм

это ты попробуй приведи пример фп языка популярного))

эликсир

Раби

спасибо за вопрос кстати

эликсир

ппц уж популярный))

походу надо написать огромный текст почему имутабельность в руби тащит

даже на рубишных митапах про него рассказывают

шах и мат

и почему мутировать все равно надо

и почему мутировать все равно надо

а чёб тебе в секреты бекенда недельку не првоести

Питон, перл, раби - вполне себе фп языки ;)

Питон, перл, раби - вполне себе фп языки ;)

лисп оопшный так то

как у тебя питон(не пайтон) и раби(не руби) одновременно?

а чёб тебе в секреты бекенда недельку не првоести

да нафига