почему-то последнее время Gson у меня ассоциируется с некрофилией

А что вместо него?

jackson

у него и поддержка котлина уже из коробки

Гсон вроде для андроида используют, джексон немного для этого жЫрноват

у него и поддержка котлина уже из коробки

О, это позитивные новости, спасибо.

То есть дата-классы он норм схавает?

да

moshi, мб? тоже поддержка котлина из коробки и от square

толкьо надо подручить еще jackson-kotlin зависимость

это не называется «из коробки»

А если для бэкэнда, то я всегда джексон беру. У него не только поддержка котлина, но и ямла, хмл-а, джава.тайм и тд

я думаю до джексона по фичам всем далековато будет, это комбаин

это не называется «из коробки»

плагин стандартный

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

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

Да нет, я просто не особо много с проекциями типов работал, тут скорее по этой части вопрос – будет ли нормально идти матчинг, или потрется все до Any и я буду вечно первый десериализатор ловить.

Прикол, а SuccessOrFailure<T> оказывается переименовали в Result<T>

А кто-нибудь знает, может как-то можно нормально протестировать код с корутинами с учетом асинхронности? Условно, есть презентер, внутри которого запускается корутина, хочется проверить, что в зависимости от результата вызываются нужные методы. Несмотря на то, что Сами Deferred замоканы как GlobalScope.async { value } получилось протестировать только так @Test fun test() = runBlocking { val presenter = ... // setup presenter.action() delay(100) verify(...) }

Как-то можно от delay избавиться?

yield()

Написать кастомный шедулер?

Прикол, а SuccessOrFailure<T> оказывается переименовали в Result<T>

Хде? В м2 вроде нет ещё

Хде? В м2 вроде нет ещё

https://github.com/JetBrains/kotlin/commit/feb7239189e73733e0527da7ffc1751a8dda9d15

https://github.com/JetBrains/kotlin/commit/feb7239189e73733e0527da7ffc1751a8dda9d15

Алилуя

yield()

Можно подробнее?

Написать кастомный шедулер?

Не знаю, может как раз проблема в том, чт я использую Dispatchers.Unconfined

Можно подробнее?

ну, в корутинах есть функция, которая суспендит корутину, уступая пул другим

ну, в корутинах есть функция, которая суспендит корутину, уступая пул другим

А как это может помочь? проблема в том, что verify выполняется раньше, чем действие завершилось

для RX у нас был advanceBy, но здесь delay реально застопит выполнение теста

А как это может помочь? проблема в том, что verify выполняется раньше, чем действие завершилось

А что за действие, почему его нужно ждать?

Ну само действие — чтение из базы, но я его мокаю в этом тесте.

Ну то есть оно синхронное и мгновенное?

Должно быть да

Вроде спасает добавление join'ов на Deferred, но получается слишком многословно как-то

Прикол, а SuccessOrFailure<T> оказывается переименовали в Result<T>

а flatMap так и не приделали?

Вроде спасает добавление join'ов на Deferred, но получается слишком многословно как-то

так то это правильное решение и я бы не сказал что многословное

мало кода != правильно != читаемо

так то это правильное решение и я бы не сказал что многословное

Спасибо =)

Вроде спасает добавление join'ов на Deferred, но получается слишком многословно как-то

Ты ж в котлине, напиши экстеншн

мало кода != правильно != читаемо

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

Вроде спасает добавление join'ов на Deferred, но получается слишком многословно как-то

Вам просто нужно в моке сделать какой-нибудь летч и ожидать его

Ты ж в котлине, напиши экстеншн

Да, уже, как раз то

Вам просто нужно в моке сделать какой-нибудь летч и ожидать его

Тоже вариант, спасибо

Тоже вариант, спасибо

Самый действенный вариант по моей практике

у кого нибудь есть тестовый проект с корутинами и с Clean Arch?(Новичок)

у кого нибудь есть тестовый проект с корутинами и с Clean Arch?(Новичок)

с корутинами у меня есть

а, clean arch это про андроид. сорян, у меня spring там

а, clean arch это про андроид. сорян, у меня spring там

» clean arch Давно?

у кого нибудь есть тестовый проект с корутинами и с Clean Arch?(Новичок)

их на гитхабе пруд пруди

но они просто отвратительны

у кого нибудь есть тестовый проект с корутинами и с Clean Arch?(Новичок)

Ну, ты можешь смотреть примеры с Clean Architecture, но без корутин, поиграться и самостоятельно переписать общение между слоями на корутины. Это не должно быть сложно. И отдельно смотреть примеры кода с корутинами.

у кого нибудь есть тестовый проект с корутинами и с Clean Arch?(Новичок)

(это также, как без корутин, только с корутинами (вместо колбеков))

(это также, как без корутин, только с корутинами (вместо колбеков))

s/коллбеков/любого другого способа связывать слои/g

Я видел недавнее обновление, и не совсем понял, вроде все корутинбилдеры выпилили

а flatMap так и не приделали?

https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/coroutines/src/kotlin/Result.kt вроде все также (те нет)

https://github.com/JetBrains/kotlin/blob/master/libraries/stdlib/coroutines/src/kotlin/Result.kt вроде все также (те нет)

придется экстеншн запилить

Я видел недавнее обновление, и не совсем понял, вроде все корутинбилдеры выпилили

не выпилили, просто добавили явно от кого они работают, от GlobalScope. или от другого билдера (как обычно)

придется экстеншн запилить

подумой ? а если ли смысл (это же не идиоматичный котлин получается) P.S. почему все натягивают (котлин) сову-на-глобус, а не берут подходящий язык ?

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

и под соусом котлина легче продать сову на глобусе

и под соусом котлина легче продать сову на глобусе

А ты думаешь для "обычных продакшен программ", имеет смысл упарываться монадами/arrow в неприспобленном языке? (немножко похоже не карго-культ) (для НЕ продакшен - можно на чем угодно же писать)

и под соусом котлина легче продать сову на глобусе

На привьюшке этого сообщения я прям заинтересовался))

А ты думаешь для "обычных продакшен программ", имеет смысл упарываться монадами/arrow в неприспобленном языке? (немножко похоже не карго-культ) (для НЕ продакшен - можно на чем угодно же писать)

Давай так, сразу уточни, что ты понимаешь под "обычные продакшен программы"? Каковы критерии

и о какой предметной области идет речь

А ты думаешь для "обычных продакшен программ", имеет смысл упарываться монадами/arrow в неприспобленном языке? (немножко похоже не карго-культ) (для НЕ продакшен - можно на чем угодно же писать)

Вы так говорите, будто математику функторов, аппликативов, монад и прочего (теорию категорий) не для построения корректных абстракций придумали, а так, по фану. Ну дак это не верно.

Давай так, сразу уточни, что ты понимаешь под "обычные продакшен программы"? Каковы критерии

mobile/интерпрайз - "простые информационные системы"

ERROR: S client not available

mobile/интерпрайз - "простые информационные системы"

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

Вы так говорите, будто математику функторов, аппликативов, монад и прочего (теорию категорий) не для построения корректных абстракций придумали, а так, по фану. Ну дак это не верно.

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

и о какой предметной области идет речь

Ну и вот это тоже определяющий фактор.

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

Ну отвечая на вопрос о смысле "упарываться": смысл в том, чтобы программировать в математически корректных, выверенных абстракциях, с хорошо определённым поведением.

подумой ? а если ли смысл (это же не идиоматичный котлин получается) P.S. почему все натягивают (котлин) сову-на-глобус, а не берут подходящий язык ?

(Тут должна быть реклама f#)

(Тут должна быть реклама f#)

??

Вы так говорите, будто математику функторов, аппликативов, монад и прочего (теорию категорий) не для построения корректных абстракций придумали, а так, по фану. Ну дак это не верно.

Ну придумали, их, предположим, как раз таки по фану. Никто не сомневается в том, что можно писать код "по науке". Вопрос в том, нужно ли.

Ну отвечая на вопрос о смысле "упарываться": смысл в том, чтобы программировать в математически корректных, выверенных абстракциях, с хорошо определённым поведением.

А пример можно? Вот какой-то реально работающей программы не на хаскеле "в математически корректных, выверенных абстракциях, с хорошо определённым поведением"?

??

и запусти это на андроид ?

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

А пример можно? Вот какой-то реально работающей программы не на хаскеле "в математически корректных, выверенных абстракциях, с хорошо определённым поведением"?

Ну sequence в Kotlin - воплне себе пример удобной и нужной монады.

mobile/интерпрайз - "простые информационные системы"

я тут строчил большой ответ, но потом передумал поддаваться на провокации

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

И круто если он будет писать на хаскеле (=> идрисе => коке/агде) дальше, а не котлине

Ну sequence в Kotlin - воплне себе пример удобной и нужной монады.

Последовательноти на котлине прямым образом наследуют стримы в яве, корнями уходят в дофункциональную эпоху. Для их понимания математика не нужна вообще.

И круто если он будет писать на хаскеле (=> идрисе => коке/агде) дальше, а не котлине

Согласен. Обычно у них к этому мозг выворачиваетя и они начинают городить какие-то сложные конструкции чтобы имитировать чистый язык на том же котлине.

Тот же паттерн матчинг

Чтобы писать на хаскелл математика не нужна

ни теория категорий, ни абстрактная алгебра

Последовательноти на котлине прямым образом наследуют стримы в яве, корнями уходят в дофункциональную эпоху. Для их понимания математика не нужна вообще.

Ну для понимания большинства монад математика не особо нужна. Она нужна, если надо свою монаду реализовать. Иначе получается как с Optional в Java - формально реализует монаду, но ассоциативности у map нету, в результате цепочку из нескольких map вызовов лучше вообще не рефакторить, если работает, иначе сломается.

Тот же паттерн матчинг

паттер матчинг - приятный сахарок, в нем нет никаких сложностей

я тут строчил большой ответ, но потом передумал поддаваться на провокации

И правильно)) Я вообще не против фп, а только за идиоматичность, "простоту" и баланс (его нащупать гораздо сложнее, чем сгородить лес из монад и трансформеров).

Чтобы писать на хаскелл математика не нужна

Оксюморон получается. Любые языки программирования - формальные системы, из которых, по возможности, удалена неоднозначность, со строгими правилами синтаксиса. То есть, по сути, это математические формализмы. Если вы не будете называть математику математикой, она он этого не станет чем-то другим.

паттер матчинг - приятный сахарок, в нем нет никаких сложностей

Просто было уже несколько не самых удачных попыток протащить его в котлин. Типа без него не едят

Просто было уже несколько не самых удачных попыток протащить его в котлин. Типа без него не едят

просто в Kotlin есть when (value) { is Something -> } многие, кто сталкивался с паттерн-матчингом думают: "его чуть-чуть докрутить и будет мощная штука из языка Х которой мне так нравилось пользоваться". Если бы сделали простой switch никто бы не топил за паттерн-матчинг так сильно

Не думаю

В любой язык с хоть какой-то поддержкой функционльного программирования его будут пытаться тащить. Просто по привычке

Просто было уже несколько не самых удачных попыток протащить его в котлин. Типа без него не едят

Ну в текущем виде в Kotlin есть очень ограниченный pattern destructuring (не работает в случае nested destructuring). Вообще pattern matchig - неотъемлемая часть типа альтернативы в типизированном лямбда исчислении. Так что его пытаются протащить не по привычке, а так как есть поддержка типизированных лямбд и есть поддержка альтенатив (sealed classes)

Проблема в том, что в ктолине не нужно лямбда-исчисление

Проблема в том, что в ктолине не нужно лямбда-исчисление

Почему?

Вполне хватает обычной клеточной тьюринг-полноты

А зачем?

просто в Kotlin есть when (value) { is Something -> } многие, кто сталкивался с паттерн-матчингом думают: "его чуть-чуть докрутить и будет мощная штука из языка Х которой мне так нравилось пользоваться". Если бы сделали простой switch никто бы не топил за паттерн-матчинг так сильно

Имхо основной плюс when, в "полноте разбора вариантов", без него он и не особо полезен (и никак не решает exp-problem). Да и в языках с норм ПМ, всеравно часто используют полиморфизм (в разных видах).