и в этом тоже спасибо )

Ну вообще я бы не советовал делать подобные циклы по ссылкам. Это может привести к внезапной бесконечной рекурсии. Например: class A(bRef: () -> B) { val b: B by lazy(bRef) override fun toString(): String = "A(b=$b)" } class B(val a: A) { override fun toString(): String = "B(a=$a)" } Теперь попытка вызвать toString у любого из объектов типа A или B приведёт к StackOverflowError, так как A.toString содержит шаблон, в котором неявно вызывается B.toString, который содержит шаблон, в котором неявно вызывается A.toString ...

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

Это только у меня, или serialization плагин стабильно ломает идею?

Это только у меня, или serialization плагин стабильно ломает идею?

какая ошибка?

Что-то невнятное. Сейчас включу его обратно и посмотртю

java.lang.AbstractMethodError

at org.jetbrains.kotlin.resolve.extensions.SyntheticResolveExtension$Companion$getInstance$1.generateSyntheticMethods(SyntheticResolveExtension.kt:70)

Рушится на реализации сериализатора

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

есть некоторый data class FormState состоящий из компонентов вида data class SelectState, data class TextState. есть обсервабл излучающий этот FormState, однако если юзать оператор distinctUntilChanged то консюмер не получает новый стейт если внутри какого либо SelectState/TextState что то поменялось, т.е. я так понял equals не отрабатывает

это самому надо писать что ли? т.е. типа equals работает только для простых типов но не для сложных конструкций?

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

Это я все знаю. Мне тогда проще плагин отключить. Я так понял, что он позволяет линтеру не ругаться на методы, которые генерятся плагином.

это самому надо писать что ли? т.е. типа equals работает только для простых типов но не для сложных конструкций?

код покажи

это самому надо писать что ли? т.е. типа equals работает только для простых типов но не для сложных конструкций?

equals работает для всего, для чего он прописан. Но есть сравнение по ссылке, надо проверить, что не оно используется

есть некоторый data class FormState состоящий из компонентов вида data class SelectState, data class TextState. есть обсервабл излучающий этот FormState, однако если юзать оператор distinctUntilChanged то консюмер не получает новый стейт если внутри какого либо SelectState/TextState что то поменялось, т.е. я так понял equals не отрабатывает

data class вызывает equals вложенных классов, можешь это проверить cmd + shift + a -> show kotlin bytecode

а, добавил явный компаратор и стало работать как задумано .distinctUntilChanged { t1: FormState, t2: FormState -> t1 != t2 }

а, добавил явный компаратор и стало работать как задумано .distinctUntilChanged { t1: FormState, t2: FormState -> t1 != t2 }

comparator должен возвращать true, когда обьекты равны, а не наоборот

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

ребят, какие сейчас фреймворки для тестирования на котлине в почете? Spek, Mokk, KotlinTest? Есть ли что-то еще интересное для тестов, особенно в контексте андроида?

ребят, какие сейчас фреймворки для тестирования на котлине в почете? Spek, Mokk, KotlinTest? Есть ли что-то еще интересное для тестов, особенно в контексте андроида?

Junit4

Junit4

+Mockito-Kotlin?

+ kotlin-test-junit4

+Mockito-Kotlin?

Не пользуюсь моками

Если у вас Даггер нормально заведён по гайдам - моки не нужны

Если у вас Даггер нормально заведён по гайдам - моки не нужны

тестовые инмплементации через него подсовывать?

вроде как сам гугл рекомендует так не делать

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

а что-то более kotlin way чем AssertJ сущетсвует в природе?

а что-то более kotlin way чем AssertJ сущетсвует в природе?

kotlin-test

kotlin-test

А что там есть? На вид, тот же Spek

Это просто обертка над Junit

кросс-платформенная

Прикол, там даже есть property-based тесты https://github.com/kotlintest/kotlintest/blob/master/doc/reference.md#property-based-testing-

я имел ввиду https://kotlinlang.org/api/latest/kotlin.test/index.html

Допустим, я хочу объявить общие для всех под-проектов зависимости. Если с репозиториями все просто, то с зависимостями что-то не могу найти вменяемой доки, может кто-то навести на путь истинный? allprojects { def repositories = project.getRepositories() def dependencies = project.getDependencies() repositories.add(repositories.mavenCentral()) repositories.add(repositories.jcenter()) dependencies.??? }

я имел ввиду https://kotlinlang.org/api/latest/kotlin.test/index.html

хочется еще услышать какие-то более "хипстерские" мнения =))

Допустим, я хочу объявить общие для всех под-проектов зависимости. Если с репозиториями все просто, то с зависимостями что-то не могу найти вменяемой доки, может кто-то навести на путь истинный? allprojects { def repositories = project.getRepositories() def dependencies = project.getDependencies() repositories.add(repositories.mavenCentral()) repositories.add(repositories.jcenter()) dependencies.??? }

subprojects { subproject -> afterEvaluate { if (subproject.plugins.hasPlugin('kotlin') || subproject.plugins.hasPlugin('kotlin-android')) { dependencies { implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3-M2' } } } }

subprojects { subproject -> afterEvaluate { if (subproject.plugins.hasPlugin('kotlin') || subproject.plugins.hasPlugin('kotlin-android')) { dependencies { implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3-M2' } } } }

спасибо :)

хочется еще услышать какие-то более "хипстерские" мнения =))

Truth интересный

Хотя они все мало полезные какие-то

Для красивого диффа больших объектов можно взять javers

subprojects { subproject -> afterEvaluate { if (subproject.plugins.hasPlugin('kotlin') || subproject.plugins.hasPlugin('kotlin-android')) { dependencies { implementation 'org.jetbrains.kotlin:kotlin-stdlib-jdk8:1.3-M2' } } } }

Иииии нет, не работает. Гист: https://gist.github.com/komigor/4a6176bcd69c03991c7e13740da13142

Иииии нет, не работает. Гист: https://gist.github.com/komigor/4a6176bcd69c03991c7e13740da13142

Мне понравилось как решена проблема тут https://github.com/k0shk0sh/FastHub/tree/fasthub/fasthub-v5

Иииии нет, не работает. Гист: https://gist.github.com/komigor/4a6176bcd69c03991c7e13740da13142

яб попробывал таки указание репозитория вынести в allprojects и версии компилятора котлина поместил под иф с проверкой что есть плуг котлина так как то логичнее. Ну и без ошибки не понятно чо не так )

У меня то что я запостил работает =)

Мне понравилось как решена проблема тут https://github.com/k0shk0sh/FastHub/tree/fasthub/fasthub-v5

И все-таки это не совсем то, чего мне хотелось бы :)

Иииии нет, не работает. Гист: https://gist.github.com/komigor/4a6176bcd69c03991c7e13740da13142

и вынь блок сабпрожект из билдскрипта, его в корень

так оно точно работать не будет =)

и вынь блок сабпрожект из билдскрипта, его в корень

вынес в allprojects то, что было в subprojects, все заработало

ну и ладно =)

Кто-нибудь с kotlinx.serialization всерьез работал? Я не могу понять, как сделать кастомный сериализатор, чтобы он работал для JSON и прочего CBOR. Как делать бинарный сериализатор - понятно, KInput и KOutput. Но каким образом эта штука узнает, что писать в json?

Может кто-нибудь посоветовать хороший фреймворк для краулинга в идеале написанный на kotlin?

Может кто-нибудь посоветовать хороший фреймворк для краулинга в идеале написанный на kotlin?

что есть краулинг? собирать данные с сайтецов?

что есть краулинг? собирать данные с сайтецов?

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

Кто-нибудь с kotlinx.serialization всерьез работал? Я не могу понять, как сделать кастомный сериализатор, чтобы он работал для JSON и прочего CBOR. Как делать бинарный сериализатор - понятно, KInput и KOutput. Но каким образом эта штука узнает, что писать в json?

//cc @sandwwraith

Может кто-нибудь посоветовать хороший фреймворк для краулинга в идеале написанный на kotlin?

Вроде бы Beautiful Soup был когда то

Кто-нибудь с kotlinx.serialization всерьез работал? Я не могу понять, как сделать кастомный сериализатор, чтобы он работал для JSON и прочего CBOR. Как делать бинарный сериализатор - понятно, KInput и KOutput. Но каким образом эта штука узнает, что писать в json?

а почему вы думаете что KOutput не может писать в json ?

Ну вообще я бы не советовал делать подобные циклы по ссылкам. Это может привести к внезапной бесконечной рекурсии. Например: class A(bRef: () -> B) { val b: B by lazy(bRef) override fun toString(): String = "A(b=$b)" } class B(val a: A) { override fun toString(): String = "B(a=$a)" } Теперь попытка вызвать toString у любого из объектов типа A или B приведёт к StackOverflowError, так как A.toString содержит шаблон, в котором неявно вызывается B.toString, который содержит шаблон, в котором неявно вызывается A.toString ...

циклы в объектах могут быть просто в силу природы этих объектов это обычное дело если бы от них было всегда легко избавиться, то не надо было бы изобретать всякие сложные gc, простой подсчет ссылок решал бы все вопросы а так сплошь и рядом циклы и gc в каждом втором языке

а почему вы думаете что KOutput не может писать в json ?

Судя по коду, может, но я не понимаю, как. Имен полей он не знает

они берутся из KSerialClassDesc по переданному индексу

циклы в объектах могут быть просто в силу природы этих объектов это обычное дело если бы от них было всегда легко избавиться, то не надо было бы изобретать всякие сложные gc, простой подсчет ссылок решал бы все вопросы а так сплошь и рядом циклы и gc в каждом втором языке

Могут. Я просто написал, что это как раз такой случай, так как вы изначально говорили о дата классах, а для них естественным образом определяется структурная эквивалентность и toString, которые, при наивной имплементации, дадут бесконечную рекурсию.

они берутся из KSerialClassDesc по переданному индексу

Спасибо. Об этом не подумал. Буду завтра шерстить код на эту тему

можно сгенерированный код посмотреть через show kotlin bytecode - decompile to java, ну или саму реализацию json’a

Я посмотрел. Там все довольно запутанно и без документации. Сразу не разобрался.

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

ERROR: S client not available

Без документации – это да ? Можно почитать KEEP, который разъясняет, для чего нужны пачки методов. Но там имена интерфейсов новые

что то кроме срача про DI полезное было?

циклы в объектах могут быть просто в силу природы этих объектов это обычное дело если бы от них было всегда легко избавиться, то не надо было бы изобретать всякие сложные gc, простой подсчет ссылок решал бы все вопросы а так сплошь и рядом циклы и gc в каждом втором языке

прокси объекты спасут отца цикличных ссылок

это по классике, везде так решается

кстати, что котлин предоставляет в качестве object proxy engine? только jvm proxy?

прокси объекты спасут отца цикличных ссылок

А вы знаете толк в костыльных решениях

А вы знаете толк в костыльных решениях

это не костыли, а элегантное решение в реальном мире

не все и не везде just simple

мне кажется все(ну по крайней мере большинство) из тех кто топит за ручную сборку и прочие kiss не заглядывали даже в gof

мне кажется все(ну по крайней мере большинство) из тех кто топит за ручную сборку и прочие kiss не заглядывали даже в gof

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

не все и не везде just simple

Если это не так, то возможно что то пишете не так ¯\_(ツ)_/¯

Если сможете привести пример где без таких костылей вроде dynamic proxy не обойтись, я признаю свою неправоту

если обещаете не скатываться в срач, то приведу :)

если обещаете не скатываться в срач, то приведу :)

Клянусь на библии

Клянусь на библии

ок, поставил на заметку, вернусь через пару часов и отпишу, пока работа кипит

циклы в объектах могут быть просто в силу природы этих объектов это обычное дело если бы от них было всегда легко избавиться, то не надо было бы изобретать всякие сложные gc, простой подсчет ссылок решал бы все вопросы а так сплошь и рядом циклы и gc в каждом втором языке

Циклы в объектах - да, обычное дело. Но натягивать циклы на иммутабельные дата классы лучше не надо. Они не для этого. Да и практически всегда циклические зависимости можно разрулить, введя посредника

мне кажется все(ну по крайней мере большинство) из тех кто топит за ручную сборку и прочие kiss не заглядывали даже в gof

А зачем? Описания этих (и некоторых других) антипаттернов давно есть в Википедии.

Циклы в объектах - да, обычное дело. Но натягивать циклы на иммутабельные дата классы лучше не надо. Они не для этого. Да и практически всегда циклические зависимости можно разрулить, введя посредника

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

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

Я про циклы в обьектах типа сервисов и всякого такого, не в value-objects

Я про циклы в обьектах типа сервисов и всякого такого, не в value-objects

А, ну это уже архитектурные проблемы

Если сможете привести пример где без таких костылей вроде dynamic proxy не обойтись, я признаю свою неправоту

Я делал такие костыли, когда нужно было изменить урл, на который ходит всё приложение. Лечится полной пересборкой графа объектов, усугубляется состоянием в них.

Я делал такие костыли, когда нужно было изменить урл, на который ходит всё приложение. Лечится полной пересборкой графа объектов, усугубляется состоянием в них.

Звучит как работа для прокси

Циклы в объектах - да, обычное дело. Но натягивать циклы на иммутабельные дата классы лучше не надо. Они не для этого. Да и практически всегда циклические зависимости можно разрулить, введя посредника

Бывает всякое. Жизнь богаче представлений программиста об идеальной архитектуре. Простой пример: есть две карты в игре. На каждой стоит телепорт, который ведет на другую карту. Карта хранит ссылки на все объекты, которые на ней стоят, в том числе телепорты. Телепорты хранят ссылки на соседнюю карту. Цикл: карта A => телепорт A => карта B => телепорт B => карта A

Бывает всякое. Жизнь богаче представлений программиста об идеальной архитектуре. Простой пример: есть две карты в игре. На каждой стоит телепорт, который ведет на другую карту. Карта хранит ссылки на все объекты, которые на ней стоят, в том числе телепорты. Телепорты хранят ссылки на соседнюю карту. Цикл: карта A => телепорт A => карта B => телепорт B => карта A

и телепорты умеют прям инстанциировать карту со всеми обьектами в игре? Или они обращаются к менеджеру сцен с просьбой "Заргрузи мне эту карту"? По крайней мере, в Unity 3D телепорты должны хранить только id карты которую они должны загрузить и ссылку на менеджер сцен, который выступает медиатором между сценами

Бывает всякое. Жизнь богаче представлений программиста об идеальной архитектуре. Простой пример: есть две карты в игре. На каждой стоит телепорт, который ведет на другую карту. Карта хранит ссылки на все объекты, которые на ней стоят, в том числе телепорты. Телепорты хранят ссылки на соседнюю карту. Цикл: карта A => телепорт A => карта B => телепорт B => карта A

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

и телепорты умеют прям инстанциировать карту со всеми обьектами в игре? Или они обращаются к менеджеру сцен с просьбой "Заргрузи мне эту карту"? По крайней мере, в Unity 3D телепорты должны хранить только id карты которую они должны загрузить и ссылку на менеджер сцен, который выступает медиатором между сценами

это описатели статические данных, ресурсы, не динамика и это не Unity

это описатели статические данных, ресурсы, не динамика и это не Unity

ок, если это описано в ресурсах, то ты не вставляешь в объект телепорт целиком карту

ты оставляешь ссылку на нее

например, id

ок, если это описано в ресурсах, то ты не вставляешь в объект телепорт целиком карту

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

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

ну типа а что мешает в конфиге ссылаться на id?