разве в джаву нужно отправлять мутабл?

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

... мне нужен агрегат с двумя Map внутри. При этом объекты в разных Map ссылаются друг на друга. Я так думал хранить граф

очевидное правило - внутри иммутейбла хранить только иммутейбл. То есть у нас есть иммутейбл агрегат, с иммутейбл списоком из иммутейбл элементов. По идеологии доступ к списку строго через методы агрегата. То есть получить/записать список можно только через геттер сеттер. Т.к. список иммутейбл, то можно спокойно отдавать ссылку на внутренний, все равно ничего не сделать. Что копируй что не копируй.

я тебе привёл пример одного уровня вложенности, если их будет 3 то team.copy(lead = team.lead.copy(age = team.lead.age + 1))) ну дурацкие примеры

а пофиг =)

все внутри - иммутейбл

можно спокойно копировать по ссылкам как я понимаю

а вот как обновить элемент внутри Map/List?

разве в джаву нужно отправлять мутабл?

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

(я на самом деле считаю что вся эта затея с immutable - модная фигня. Скоко работал с изменениями по ссылкам, грязными функциями и прочим - проблем не было. И читал такой же код, вплоть до натурально индусского. Ничо, все понятно было.)

нахер такую иммутабельность тогда, это маразм

просто меру знать надо

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

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

ты главное сам ничего не сможешь сделать

просто меру знать надо

(а кому не хватает - идут в скалу ?)

И все же сама идея занятна. С этим действиетльно будет очень просто потом работать.

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

просто меру знать надо

ну так оно или иммутабельно или нет =)

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

... это нужно чтобы прогер который код читать не может почитал его...

напиши экстеншонов для иммутабельных списков)))

Короче )

(а кому не хватает - идут в скалу ?)

и что там всё во всю глубину иммутабельно?

Да?

Короче, иммутабельный объект с иммутабельным списком иммутабельных объектов - он получается весь де факто иммутабельный, на какие бы его части я не ссылался? Так? =)

а нахрена тебе такая иммутабельность?

ты прикинь какая это нагрузка на gc

мало-мальски объёмная операция превращается в ад

и что там всё во всю глубину иммутабельно?

Не хочу офтопить, лучше обсудить в их чате. В основном все как в Котлин, но у них свои персистетные коллекции (и это вызывает большие проблемы в интеропе)

скала это тот ещё гемор

а нахрена тебе такая иммутабельность?

Ну чтоб... все "правильно" было =) Чтобы нельзя было агрегат привести в несогласованное состояние.

Короче, иммутабельный объект с иммутабельным списком иммутабельных объектов - он получается весь де факто иммутабельный, на какие бы его части я не ссылался? Так? =)

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

"правильно" не обязательно эффективно и нужно

Короче, иммутабельный объект с иммутабельным списком иммутабельных объектов - он получается весь де факто иммутабельный, на какие бы его части я не ссылался? Так? =)

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

ну понятно что если вообще извернуться то можно сделать это дело мутабельным. Это все же по больше чайсти защита от ненарочного неверного использования. А не от специального "взлома"

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

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

ну понятно что если вообще извернуться то можно сделать это дело мутабельным. Это все же по больше чайсти защита от ненарочного неверного использования. А не от специального "взлома"

ну плюс это доп информация для компилятора. на уровне LLVM IR все (точно не знаю) значения на стеке иммутабельны. мб попроще работать с иммутабельным языком

ну да, много вложенных copy это же не проблема...

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

https://github.com/fablue/imko еще один с ума сходит

Балин

https://github.com/fablue/imko еще один с ума сходит

ну норм

Хранить то мне это дело как.. конструктор же нужен

Через констурктор можно черти что повтыкать

хз о чём ты

хз о чём ты

Идея в том, что раз уж стал (вообще то тут меня к этому принудили val, nonnull) использовать immutable, то и агрегаты тоже должны быть как положено по ddd - immutable. Простой объект можно просто сделать immutable: data class + val + все в конструкторе. А вот как сделать составной объект immutable. Пока что идея такая же - все внутренности корневого immutable тоже должны быть imm (замучался писать), указаны через val. Но вот агрегат должен быть в любой момент времени согласованным. А значит если там два списка залинкованных друг на друга - нельзя просто так взять и создать его через конструктор. Сам orm я думаю это сделает через рефлексию, фиг с ним. Но надо как то сам конструктор защитить. Чтобы в клиентском коде было сравнительно невозможно привести его в несогласованное состояние. Наверно просто навесить модификатор доступа на этот констурктор.

ну циклические ссылки в иммутабл сложновато но реально

мб пример кода где они нужны?

ну как-как, через мэни-то-мэни обджект

мб пример кода где они нужны?

Окей, вот моя реальная задача. Объект бизнес-процесса (большой прямоугольник) содержит лейны (lanes, средний прямоугольник, к лейну крепится исполнитель задачи), лейны содержат активити (маленький прямоугольник, задача). Мало того (это можно опустить пока), есть ещё список переходов. У активити есть список переходов в другие активити) Только не отсылайте меня к фреймворку activity. Все бы хорошо, но часто требуется получить все лейны какого-то активити и наоборот. Я очень не хочу это делать через циклы. Хотя, признаться, эту структуру в NoSql я делаю первый раз, может я что то упускаю.

Получается объект процесса, в нем две мапы - лейны и активити. У них есть внутренние уникальные имена (считай Id)

Элементы мап друг на друга смотрят. Можно без ссылок, просто по идшники

В идеале это все сразу и в бд сохранять

Я не хочу чтобы этот агрегат мог прийти в несогласованное состояние. Если сделать ссылки - то при изменении последнего активити по цепочке копировать придется вообще все. Не весело. Ну и не особо в бд сохранится. Можно тогда просто ид хранить а ссылаемый объект.

Можно ещё проще - хранить рядом ещё мапы со связью ид-ид

Уверен, что я где-то читал про православный подход к решению конкретно данной задачи

при чем типовому решению, даже название было

Уверен, что я где-то читал про православный подход к решению конкретно данной задачи

Ещё есть зацепки?)

Сейчас попробую загуглить :)

data class Child(val parent: Parent) class Parent ( createChild: (Parent) -> Child ) { val child = createChild(this) } это как решить проблему с одной циклической зависимостью) ну и датакласс здесь ок не выйдет при множестве: да нужны внешние мапы скорей всего

Я сформулировал вопрос у себя в голове и вышел с этим вопросом в интернет. Результат меня, впрочем, не удивил - все найденные варианты many-to-many в nosql сделаны через вспомогательные "таблицы"

Я сформулировал вопрос у себя в голове и вышел с этим вопросом в интернет. Результат меня, впрочем, не удивил - все найденные варианты many-to-many в nosql сделаны через вспомогательные "таблицы"

Основная проблема в том, чтобы сделать объект бизнес процесса агрегатом по DDD.

combot.org/chat/-1001032833563

?

Я просто так нажал

силен!!!

... ???

Да я ради интереса нажал.... Что такого?

Я кажется тупанул... Для data класса не обязательно вообще все помещать в конструктор.

Завтра попробую

парни, дайте ссылку на котлин оффтоп чат, пожалуйста

Так это и есть он.

А ну ок. Кто нибудь писал на clojure?

А ну ок. Кто нибудь писал на clojure?

не писал но хочу посмотреть следующий вопрос

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

Логично спрашивать в @clojure_ru или если пофлудить, то в @jvmchat (там точно оценят и выскажут непредвзятое мнение ?). Imho хороший язык для ФП, без лишней ленивости и io-монадок, жаль только динамический (еще и в ReactNative могет). Советую посмотреть на youtube доклады Николая Рыжикова - отлично рассказывает.

Если память не изменяет - тут не так давно jOOQ обсуждали. Хотел спросить, где собственно его подтягивать для котлина?

Логично спрашивать в @clojure_ru или если пофлудить, то в @jvmchat (там точно оценят и выскажут непредвзятое мнение ?). Imho хороший язык для ФП, без лишней ленивости и io-монадок, жаль только динамический (еще и в ReactNative могет). Советую посмотреть на youtube доклады Николая Рыжикова - отлично рассказывает.

Спасибо

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

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

Если память не изменяет - тут не так давно jOOQ обсуждали. Хотел спросить, где собственно его подтягивать для котлина?

Он генерит пока джава классы, так что не нужна особая версия jooq

Он генерит пока джава классы, так что не нужна особая версия jooq

Классно, сейчас тыркаюсь с ним. Такой вопрос - а как там нормально сделать prepared insert (если можно)?

Static statements vs. Prepared Statements https://www.jooq.org/doc/3.9/manual/sql-execution/statement-type/

Вот это думаю поможет

Т.е. по умолчанию все prepared