Https://Gist.Github.Com/Nevdokimof/Bc08536d4a4c7e1834373fd628340eae Подскажите, это правильный способ распараллелить несколько вызовов и объединить их

результат? таких вызовов в одной транзакции штук 5, порядок не важен

может, можно сделать лучше?

Зачем скоуп на каждый вызов создавать? Зачем их вообще создавать

так async {} это экстеншн для скоупа, а получить текущий скоуп в suspend блоке похоже что нельзя, ну или я не нашел как

suspend fun foo() { val scope = CoroutineScope(coroutineContext) } @noraltavir это будет работать?)

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

Будет, но это сломает немножко structured concurrency

для scope и context пригодился бы супер развёрнутый туториал, разные примеры и разжёваная дока по advanced применению

понял, спасибо

В принципе пошло бы что-то вроде suspend fun requestResult(): SomeResult = coroutineScope{ ... } flow{ while(true){ requestRestult() } } Разумеется, если там цикл. Если там однократный запрос, то Flow там вообще не надо и нельзя использовать.

У вас в коде однократный запрос. Он действительно однократный?

да, а почему flow нельзя использовать в таком случае? только после этого вопроса понял что можно обойтись suspend функцией)

Потому что он не для этого сделан вообще. Это соврешенно непростительный RX головного мозга. Если запрос однократный то просто так: fun CoroutineScope.requestResult() : Deferred<SomeResult> = async{ ... } И все. Если не надо создавать скоуп/возможность отмены, то просто суспенд функция

спасибо еще раз, у меня прям мир перевернулся

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

Я рад. Вообще типичная проблема у людей с RX. В RX есть только один асинхронный примитив - поток. В корутинах их существенно больше. И не надо использовать тяжеловесные и неудобные вещи там, где можно сделать все существенно красивее.

Отмены нет

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

Тут согласен

Справедливости ради, там есть и Single, и Maybe, просто из-за природы рыкса они выглядят так же. И вот этим двоим товарищам suspend суть прямая замена.

Я знаю, но Single - это как раз костыль для спасения от того факта, что там нет ничего, кроме потоков.

А Future/CompletableFuture - это костыль для спасения от того, что в языке нет корутин?

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

Композировать неудобно, да, хороший контракт не придумали. С другой стороны, композировать синглы удобно, и они семантически являются тем же самым, что и Future и Deferred

А чем композиция синглов лучше, чем композиция CF? Те же самые then.

У меня лично апишка фьюч головокружение вызывает. Если кому-то удобно, ладно, спорить не буду. Прошу обратить внимание на вторую часть моего сообщения про семантику

А zip там есть? Это чуть ли не самое удобное в RX

А чего там семантического? По сути один оператор с несколькими вариациями. Вопрос же был исходно не в том, как ты композируешь эту штуку, а как ты ее исходно получаешь. Для того, чтобы получить единичный элемент потока, тебе надо построить этот поток, потом отфильтровать первый элемент (при этом отследив, что и построение и вычитывание проходят в правильных окружениях).

Чего? Single.create { yourCodeThatWillYieldValueHere() }

Я тебя прям не узнал в гриме https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html#thenCombine-java.util.concurrent.CompletionStage-java.util.function.BiFunction-

Ну хорошо, убедил, не так сложно (правда тут нет окружения).

Богатым буду )) надо как-то будет посмотреть что там в CF, хотя с корутинами не нужно ни то, ни другое

При наличии корутин CF не нужен, это точно

канеш есть