Можно ли Deferred рассматривать как замену ListenableFuture

Question

Можно ли Deferred рассматривать как замену ListenableFuture или CompletableFuture

altavir · Answer

Про первое не знаю про второе есть CompletableDeferred который является аналогом

altavir · Answer

Только зависимости по другому подключаются

beholder · Answer

Первое из Google Guava

beholder · Answer

Хочется тут в систему добавить удалённые асинхронные вызовы и не знаю взять ли пока CompletableFuture или сразу на Котлине заморочиться

altavir · Answer

Ну корутины удобнее Если у вас уже библиотека подключена и не нужна обратная совместимость с джавой рекомендую

beholder · Answer

Котлин сам использую широко но корутины ещё нет

altavir · Answer

Критичный момент это джава Корутины обратно не шибко совместимы

beholder · Answer

Об обратной совместимости можно не беспокоиться

altavir · Answer

Ну тогда если 1 мб лишней зависимости не волнует берите не пожалеете

gildor · Answer

Если использование из Java не проблема то однозначно корутины Но на самом деле Deferred в 95 не нужен совсем нужны только suspend функции Deferred почти никогда не должен появлятся в публичном API Я бы рекомендовал для начала прочесть официальный гайд <https kotlinlang org docs reference coroutines coroutines guide html>

beholder · Answer

У меня есть интерфейсы на клиенте которые удалённо вызывают сервер реализовано через java lang reflect Proxy но там сейчас только геттеры и сеттеры нужно добавить асинхронные методы

beholder · Answer

Как это сделать на фьючах я хотя бы представляю

gildor · Answer

ну вот эти асинхронные методы должны быть suspend внутри них можно асинхронный код использовать другие syspend функции или через адаптеры любые дрпугие асинхронные API а клиент запускает корутину через launch и вызывает эту функцию

beholder · Answer

Могу я сделать динамический прокси для suspend методов

gildor · Answer

должно быть возможно

gildor · Answer

Retrofit это делает

gildor · Answer

но это не так то элементарно

beholder · Answer

Там же вроде добавляется какой то скрытый параметр

gildor · Answer

да

beholder · Answer

Что то как то не слишком просто

elizarov · Answer

Кстати учитывая что уже не первый раз такой вопрос про Proxy для suspend functions вот написал тикет чтобы не потерялось <https youtrack jetbrains com issue KT 34399>

gildor · Answer

Если не хочетя заморачиваться с кастомными Proxy то можно юзать Deferred или даже оставить Future просто использовать адаптер и просто вызывать await на стороне клиента который использует корутины

thevery · Answer

gt Я бы рекомендовал для начала прочесть официальный гайд Там пока до сути дойдёшь уже забудешь что хотел уж лучше неофициальный блог читать там про юзкейсы написано

altavir · Answer

Да ладно Классная документация

altavir · Answer

Если надо бац бац и тама то документации на kotlinlang достаточно

thevery · Answer

Ну видимо я очень избалован rx ом

altavir · Answer

Корутины это сильно шире чем rx Если брать только функциональность rx то там будет на две странички

thevery · Answer

Ну вот я бы предпочёл эти две страницы вместо текущих 20 А ещё во flow хорошо хоть он появился мне сильно не хватает Single Maybe вместо голых suspend ов

altavir · Answer

Чего вам не хватает

thevery · Answer

Такое и у observable есть но это не соглашение на уровне контракта

gildor · Answer

зачем Flow с синглом

gildor · Answer

gt Там пока до сути дойдёшь уже забудешь что хотел Мне кажется просто пока не прочтешь и не поймешь о чем это вообще лучше не соваться Там большая часть доки как раз про юзкейсы

gildor · Answer

gt мне сильно не хватает Single Maybe вместо голых suspend ов а что хочется добится gt но это не соглашение на уровне контракта У корутинь тоже на уровне susped функций

elizarov · Answer

Можно завести `typealias Single lt T gt = suspend gt T` Но зачем

thevery · Answer

Maybe отличается от просто suspend кучей важных деталей onSuccess onError onComplete возможностью transform в том числе блокирующими вызовами блокирующие вызовы можно писать прямо в теле fromAction fromCallable и не надо заворачивать это в async withContext тредингом озаботится вызывающий

thevery · Answer

Flow это всё даёт но это всё таки Observable а не Single Maybe Ну и emit это не совсем то же самое что и fromAction к вопросу о юзкейсах собственно

elizarov · Answer

Вопрос не что дает а зачем

elizarov · Answer

Все наши эксперименты по переписываю кода с single maybe на простые suspend функции которые мы до сих пор проводили приводили к значительному упрощению и сокращению кода Поэтому вопрос зачем у меня не праздный Если есть примеры где это полезно то хотелось бы их видеть Может мы что то упускаем

elizarov · Answer

Особенно интересует вопрос про трединг Этого комментария я вообще не понял А что мешает вызывающему озаботиться тредингом при работе с suspend функциями

elizarov · Answer

Мета замечание Котлин прагматичный язык Будь у нас примеры показывающее преимущество single maybe при решении какого то широкого класса задач так мы бы их сделали

elizarov · Answer

Понятно что в Rx и Project реактор он нужны и без них не как не обойтись так как в Java нет suspend функций

thevery · Answer

Общий ответ на вопрос зачем это в первую очередь простота перехода Понятно что можно переписать всё на suspend flow и будет хорошо но на практике так бывает далеко не всегда ведь и удобнее переносить небольшие часть

thevery · Answer

Другой пример как я уже говорил transform ```single map func1 subscribeOn observeOn subscribe ``` с `suspend` вместо `single` придётся `func1` или оба `func1`+`suspend` заворачивать в `withContext` или переписывать тоже на `suspend`

thevery · Answer

Если говорить про `Maybe` то это обычно своеобразный guard типа ```maybeLoadUser map loadExtendedData subscribeOn observeOn subscribe showNotification ``` на suspend придётся делать `suspendLoadUserOrNull` и либо городить заборы либо делать early return

thevery · Answer

gt Мета замечание Котлин прагматичный язык Абсолютно согласен потому и возмущаюсь некоторыми штуками в корутинах Ручной вызов await + лишняя переменная когда нужно сделать 2 или больше разных параллельных запросов БОЛЬ даже zip и тот лучше выглядит

gildor · Answer

gt Ручной вызов await ```val a b = awaitAll async a async b ```

elizarov · Answer

< thevery> Ручной вызов await + лишняя переменная Не понял Пример можно

thevery · Answer

А там < gildor> показал выше обход проблемы собственно Совсем красиво было бы `val a by async a ` но это мы как раз год назад обсуждали

elizarov · Answer

Если я не ошибаюсь то после переписывания на suspend функции вот такой код с Maybe Single ``` maybeLoadUser map loadExtendedData subscribeOn observeOn subscribe showNotification ``` становится вот таким ``` val user = maybeLoadUser return val data = loadExtendedData user showNotification data ``` Ну а для тех кто не любит дополнительные переменные можно написать ``` maybeLoadUser let loadExtendedData let showNotification ``` В любом случае это 100 такой же как код так я если бы никаких медленных сетевых операций не было

elizarov · Answer

Для упрощения `awaitAll + async` можно сделать extension в пару строк у себя в проекте если вот прямо так часто нужно ``` val a b = awaitAllAsync a b ```

thevery · Answer

gt val user = maybeLoadUser return `maybeLoadUser` становится nullable не очень большая проблема но всё равно неявный контракт и это как раз тот early return про который я выше говорил gt val data = loadExtendedData user loadExtendedData всё равно нужно качественно на suspend переписать или завернуть в async

elizarov · Answer

Что значить качественно на suspend переписать Если у вас в Rx было `map loadExtendedData ` а не `flatMap` то я из этого делаю вывод что `loadExtendedData` это какая синхронная локальная операция достает что то из кэша Не нужно её на suspend переписывать

thevery · Answer

map от flatMap отличается тем что первая возвращает результат быстро или медленно не так принципиально а вторая Single Не должна ли быть медленная функция и так завёрнутой в Single вопрос хороший но я точно уверен что не 100 таких функций завёрнуто на практике Да банально list filter представим loadUsers вместо loadUser не очень хочется делать на ui потоке

elizarov · Answer

Ну если у вас медленная блокируящая функция не завернута в Single то вы проиграли какой то поток будет заблокировать В Rx вы можете указать поток жертвую для этого используя ` subscribeOn someBackgroundDispatcher ` С корутинами же в этом случае вы пишете `withContext someBackgroundDispatcher loadExtendedData user ` Разницы вроде как нет

thevery · Answer

Разница на мой взгляд в том что subscribeOn и так есть практически всегда и что тоже немаловажно он один на всю цепочку map filter etc

elizarov · Answer

Ну если у вас такое legacy то пишите так же и один `withContext` на всё Вреда от него не будет

thevery · Answer

Чувство прекрасного страдает