Ну каждому свое.

Есть джист? Мне кажется, что вариант дженерик в дженерике должен работать, но может я чего-то не знаю

Вот пример, где объявлено несколько таблиц/структур. Там внутри каждого поля есть Converter<T>, то есть мы знаем тип, с которым он работает, но не интерфейсы, которые он реализует. https://github.com/Miha-x64/reactive-properties/blob/master/logic-sample/src/main/kotlin/net/aquadc/propertiesSampleLogic/sql/schema.kt

Я таки настроил kotlinx-serialization в мультиплатформе. В конце концов таки взял новую градл модель и с ней все заработало через час. Но все равно уперся в том, что sealed классы не работают,

Я таки настроил kotlinx-serialization в мультиплатформе. В конце концов таки взял новую градл модель и с ней все заработало через час. Но все равно уперся в том, что sealed классы не работают,

Sealed классы надо через polymorphic Serializer, пока по-другому никак

Он не работает в common

Sealed-классы не совсем подходят, потому что я хочу обрабатывать 100500 исключений исключительно внизу try, в одном месте

Так а почему sealed классы не подходят? Делаете sealed class MyError, от которого наследуете все ваши варианты checked исключений. Потом, с помощью Either<MyError, *> монады из arrow конструируете ваш control flow pipeline, в конце которого в mapLeft или getOrHandle обрабатываете возможные исключения, возникающие при выполнении pipeline. Вот вам и практически полный аналог проверяемых исключений, который моделируется системой типов.

у него есть кажется реализация на JVM точно, + кажется на js, не уверен на счёт native-a

Да, JVM и JS есть, но нет в common

Так а почему sealed классы не подходят? Делаете sealed class MyError, от которого наследуете все ваши варианты checked исключений. Потом, с помощью Either<MyError, *> монады из arrow конструируете ваш control flow pipeline, в конце которого в mapLeft или getOrHandle обрабатываете возможные исключения, возникающие при выполнении pipeline. Вот вам и практически полный аналог проверяемых исключений, который моделируется системой типов.

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

Проверяемые исключения - тот ещё костыль в Java. Одна из проблем с ними - они плохо совместимы с анонимными функциями и вообще с ФП и ООП (с анонимными классами они тоже плохо совместимы, если что).

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

Ну тут никак. Проверяемость имеющихся исключений вы в Kotlin потеряете.

Что и случилось, вот я и искал путь, как можно этого избежать. Теперь вижу, что никак. Спасибо большое за ответ

В языке просто нет такого понятия, соответственно и нет возможности синтаксически это анализировать.

Ну с oracle jdk большие проблемы с установкой, а в openjdk вроде не будет long-support вообще (только полу-годовые релизы).

есть adoptopenjdk, вроде обещают гораздо больше чем полгода саппорта

Щас начал обновлять koin с дорелизной на релизную, всё понятно кроме одного: 'releaseContext(String): Unit' is deprecated. Please use Scope API. Как реализовать, не подскажите?

А нормально ли для ограничения доступа к методам билдера внутри билдера делать компаньон? Например у меня есть билдер у диалога, но после определенного метода я хочу чтобы ничего кроме show() вызвать нельзя было. Поэтому я сделал LocalBuilder только с методом show() и operator fun invoke(originalBuilder). Так можно вообще? Может ещё какие-то варианты есть для ограничения доступа?

Ненормально делать билдеры.

Не так чтобы ненормально, но можно сделать и дсл

Тоже отстой.

Это правда не избавит от необходимости делать контекстные классы

Тоже отстой.

Ну да, лучше сделать класс с тыщей полей в дефолтном клнструкторе

Ненормально делать билдеры.

ну мне нужен враппер над алертдиалогом прост. А там билдер)

И мне проще унаследоваться от него.

Так ладно, что насчет моего варианта?

Норм вариант

ну мне нужен враппер над алертдиалогом прост. А там билдер)

Ну ты же тогда получаешь изменяемый класс.

Хотя из билдеров получаются лучшие дсл-ы ?

Есть «пошаговые билдеры», где каждый метод возвращает экземпляр нового класса. Ну и горы классов из одного метода. Вот там можно контролировать порядок.

Хотя из билдеров получаются лучшие дсл-ы ?

более того, DSL-ы — и есть билдеры

Хотя из билдеров получаются лучшие дсл-ы ?

не до этого сейчас вообще) И одно от другого не отличается

Ненормально делать билдеры.

а что ты кстати можешь предложить?)

а что ты кстати можешь предложить?)

Конструктор или фабрику, которая создаёт объект за один вызов.

Но в случае, когда много параметров-то...

Но в случае, когда много параметров-то...

именованные норм

ну и много параметров == плохой код

Окей. С тем же алерт диалогом как быть, например. Мне надо много чего сгонфигурировать под себя

Окей. С тем же алерт диалогом как быть, например. Мне надо много чего сгонфигурировать под себя

Чего именно?

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

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

Иконка в заголовке? Можно завести класс TitleBar(icon: Drawable, text: CharSequence) Поле ввода, список, кнопки — это тело? Можно завести отдельный класс, описывающий тело. Но вообще, не вижу смысла это всё делать, когда есть именованные параметры.

именованные параметры, а потом куча if’ов? А если надо с джавы это юзать?

AlertDialog я всё же не выставлял бы наружу.

почему?

Зачем ифы? Если из джавы, тогда имеет смысл заморочиться с маленькими классами.

Хотя да, насчет ифов может я чет не так надумал

есть кто пользуется корутинами в вертиксе? )

Не-нуллабельный не боксится, если не присваивать его в Any/Number/etc

Ну это то понятно

парни подскажите, никак не могу понять, как вот это val mySharedViewModel : MySharedViewModel by sharedViewModel() записать на джаве?

public getMySharedViewModel() { realValue.getValue(); }

Есть actor конечно же

https://gist.github.com/InsanusMokrassar/0720b26e2df7584e1121ba9df7aff7b9 Сделал на акторе:)

Спасибо за подсказку, @HeapyHop и @Enleur

А ещё вопрос - runBlocking, как я понял, не рекомендуется вызывать ниоткуда, кроме main. А что тогда вызывать в остальных случаях?

А ещё вопрос - runBlocking, как я понял, не рекомендуется вызывать ниоткуда, кроме main. А что тогда вызывать в остальных случаях?

Что угодно, кроме него.) runBlocking блокирует

мне это и нужно

мне нужно, чтобы поток заблокировался до конца работы блока, но я боюсь, что вне main это как-то вызывает проблемы, потому что любое засыпание внутри может (как я понял) перевести корутину, созданную runBlocking на другой поток

мне это и нужно

Для чего тогда корутины?)

мне нужно, чтобы поток заблокировался до конца работы блока, но я боюсь, что вне main это как-то вызывает проблемы, потому что любое засыпание внутри может (как я понял) перевести корутину, созданную runBlocking на другой поток

Скоро выйдет 1.3, там будет suspend main, не нужно ничего блокировать

Для чего тогда корутины?)

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

Скоро выйдет 1.3, там будет suspend main, не нужно ничего блокировать

мне не нужен же suspend main

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

Тогда нужно блокировать поток, что такое себе, поэтому всё же лучше suspend либо не дожидаться результата.

мне не нужен же suspend main

Почему?

Тогда нужно блокировать поток, что такое себе, поэтому всё же лучше suspend либо не дожидаться результата.

там суть метода в ожидании результата:)

Тогда нужно блокировать поток, что такое себе, поэтому всё же лучше suspend либо не дожидаться результата.

Ну либо делать типо fun foo(): Deferred<Bar> = async { suspendFun() } И передавать результат в обёртке

ERROR: S client not available

Ну либо делать типо fun foo(): Deferred<Bar> = async { suspendFun() } И передавать результат в обёртке

Если бы у меня была возможность сменить сигнатуру - я бы так и сделал:)

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

В блокирующем коде runBlocking вполне норм

В блокирующем коде runBlocking вполне норм

у меня почему-то всё подвисает

причём та часть, что написана через корутины в итоге полностью работает, в отличие от блокируючей части

Если бы у меня была возможность сменить сигнатуру - я бы так и сделал:)

А в чем трабл?

В блокирующем коде runBlocking вполне норм

Например?

у меня почему-то всё подвисает

Трудно угадать почему, но видимо внутри runBlocking что-то не завершает свою работу

Например?

Например что?

А в чем трабл?

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

Например что?

Например что там нормального?

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

Хех

Например что там нормального?

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

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

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

Оторожно, трэш и угар Есть такой PR: https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9 В нём вопрос касается двух файлов: https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-b50c01624191e4c3468ab0822484defb И https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-c35464483a8aaed1fa1e593d4f280dd7 Старая система работала без семафора, но определённые нюансы уже давно толкали меня его добавить. Код до этого PR вполне себе работает.

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

Это да, но в идеальном мире, где уже всё хорошо. Я про то, что в проекте с синхронным кодом использование runBlocking - это норма, а иногда неизбежность.

Оторожно, трэш и угар Есть такой PR: https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9 В нём вопрос касается двух файлов: https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-b50c01624191e4c3468ab0822484defb И https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-c35464483a8aaed1fa1e593d4f280dd7 Старая система работала без семафора, но определённые нюансы уже давно толкали меня его добавить. Код до этого PR вполне себе работает.

https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-c35464483a8aaed1fa1e593d4f280dd7R130 Старый метод (который, судя по-всему, где-то ломается) ^ https://github.com/InsanusMokrassar/AutoPostTelegramBot/pull/9/files#diff-c35464483a8aaed1fa1e593d4f280dd7R99 Новый метод ^ (уже с suspend)

Это да, но в идеальном мире, где уже всё хорошо. Я про то, что в проекте с синхронным кодом использование runBlocking - это норма, а иногда неизбежность.

К сожалению, да.

Maven больше не нужен, теперь можно git репы прямо в gradle фигачить https://blog.gradle.org/introducing-source-dependencies

Здравствуй GO (-way) ?

Maven больше не нужен, теперь можно git репы прямо в gradle фигачить https://blog.gradle.org/introducing-source-dependencies

Ну это больше для C++ и другой нативщины А мавен как система сборки и раньше был не нужен

Ну это больше для C++ и другой нативщины А мавен как система сборки и раньше был не нужен

Написано что работает и с Kotlin

Написано что работает и с Kotlin

Работает

Написано что работает и с Kotlin

Ну я себе не представляю use case'ов для такой штуки в мире JVM. Разве что для MPP и K/N. Но вообще интересная фича.

Maven больше не нужен, теперь можно git репы прямо в gradle фигачить https://blog.gradle.org/introducing-source-dependencies

А это отличная новость

А это отличная новость

на самом деле так себе

кто-то сделает форс-пуш или удалит репу и фсё )

хотя iOS-еры как-то же живут с этим )

Jitpack же и с мавеном, и грейдлом работает

Ну я себе не представляю use case'ов для такой штуки в мире JVM. Разве что для MPP и K/N. Но вообще интересная фича.

Да, для MPP и K/N пока не завезли новый формат библиотек самое то.