Да общий тип может иметь 3 подтипа и у 3-го подтипа есть лист из 1-го и 2-го подтипов

Попробовал, не выходит из цикла пока не пройдет весь лист

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

Там должен смарткаст сработать и someObject станет нужным типом

Сложно покрыть все. Ну да документация могла быть подробней. Поэтому вы можете ее написать и сделать PR 😊😉

Думаю надо == condition поставить внутри каждого бранча а не снаружи

return someObject.list.find { it.findSome(it, condition) } как то так

Это в нужной ветке when

Всем привет) может кто сталкивался с такой задачей) Короче есть мессенджер на java, который переписываем с нуля на котлине. Все построено на webSocket.
есть некоторые моменты, когда клиент отправляет пакет на сервер - ждет ответа - и когда ответ приходит продолжается следующая логика.
для справки: у каждого пакета есть id и сервер отвечает с тем же id
На java все это было реализовано через кастомный Promise (у которого есть 3 стейта - WAIT/SUCCESS/FAIL и id) - то есть:
- есть List<Promise>
- при отправке пакета в список добавляется новый Promise с id пакета и стейт = WAIT
- тут логика замораживается
- далее при получении пакета с сервера по id ищется Promise в List<Promise> и если такой объект имеется - то его стейт меняется на SUCCESS
- и при смене стейта замороженная логика продолжает свое дело
На котлине же я хочу отказаться от кастомных промисов (ибо они очень тяжелые и "неповоротливы") - может кто что предложит? в какую сторону копать?
изучил Channel, ща копаюсь в AsynchronousFlow в доках
Если есть идеи подскажите пожалуйста. Заранее спасибо и спасибо что дочитали до конца 😊

Есть аналог в виде Deferred

Точнее, вам скорее всего нужен CompletableDeferred (ничего не напоминает? 😏)
И я делал что-то похожее на его основе.

хм. я с ним работал только в асинк/аваит с бд - а вот здесь его попробовать как-то не додумался

ща покопаемся)) Благодарю 👍

я как-то раз, когда не врубался, как его использовать, поставил одноэлементный канал... :)

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

ибо они на самом деле shared mutable

Каналы нужны везде прежде всего для коммуникации между работающими корутинами

Ну и как блокирующая очередь

Тоже пока не очень получается 😁 но копаем

ну вот на нейтиве в итоге единственный вариант сделать shared blocking queue - это изолятор, с которым неудобно работать