А, явовский

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

да это грабли джавы

ну можно наебаться

но зато удобно

хотяяя

Ты же в курсе, что Option в котлин не нужен?

И снова время митапов! Уже прошло несколько митапов из предыдущего списка, и от них остались видеозаписи: PS JAVA MEETUP #9 Kotlin: практика разработки современного языка программирования https://www.youtube.com/watch?v=zARWLUdZWXs Записей с Kotlin Meetup SPb еще нет, но должны скоро появиться тут: https://www.youtube.com/channel/UCSlqvh44HWn32t3C1XowgHQ/videos, подписывайтесь! и следите за чатом @kug_spb Записи с BKUG про Ktor и Kotlin/Native: https://www.youtube.com/watch?v=bfEJZwSmy1g&list=PLoo7Ank5cc7ELZbJ3JNWtH6pfDCZHkwTv Но на этом не все, в ближайшее время вас ждет новая порция Kotlin: Киев, 2 марта: KyivKUG - Automation with Kotlin / Animation with Kotlin https://www.meetup.com/KyivKUG/events/248094816/ Москва, 15 марта: Kotlin Meetup в Leroy Merlin. https://twitter.com/JetBrainsRu/status/966281944068739072 Киев, 24 марта: Kotlin Night Kyiv https://www.meetup.com/KyivKUG/events/246800518/

а в witer сразу нужный объект принимать не судьба?

все больше смахивает на костыли и палки

кто-нибудь использовал groupingBy?

groupBy

groupBy

42

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

в расширениях для Collection нету groupingBy, вроде

Я думаю тот кто использовал, тот знает полный путь ?

в расширениях для Collection нету groupingBy, вроде

У итерейбла есть

В 1.1 появился

и правда есть

и правда есть

Вот и я говорю есть ?

Ты же в курсе, что Option в котлин не нужен?

в чем проблема Option? map, orElse, orElseGet, монадки итд

а в witer сразу нужный объект принимать не судьба?

потому что тогда не скомпилится: Kotlin: Out-projected type 'FeatureController<out Feature>?' prohibits the use of названиеметода Пасту с контрактом кидал выше

в чем проблема Option? map, orElse, orElseGet, монадки итд

map === ?. map' === ?.let { } orElse === ?: orElseGet === ?: getter() orElseThrow === ?: throw

Если ты не используешь arrow и не имеешь HKT, то тебе нафиг это не надо

как можно использовать arrow.core.Option и не использовать arrow?)

Я не Ванга, импорты по скриншотам кода не подставляю, речь шла о джавовом Option

Разве нет?

orElse != ?: Option.fromNullable(daohui.getPayment()). orElse(daohui2.getFuckingPayment()) .orElse(daohui3.createFuckingPayment()) .getOrElse(getFuckingPayment())

речь шла о arrow.core.Option

с которым можно вот такое Option.applicative().tupled(Some(1), Some("Hello"), Some(20.0)) // Some(Tuple3(a=1, b=Hello, c=20.0)) и вот такое Option.monad().binding { val x = none<Int>().bind() val y = Some(1 + x).bind() val z = Some(1 + y).bind() x + y + z } //None

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

Я не Ванга, импорты по скриншотам кода не подставляю, речь шла о джавовом Option

в жабе Option*al*

orElse != ?: Option.fromNullable(daohui.getPayment()). orElse(daohui2.getFuckingPayment()) .orElse(daohui3.createFuckingPayment()) .getOrElse(getFuckingPayment())

Т.е. такое тебя не устраивает? get1() ?: get2() ?: get3() ?: getDefault()

Я б не стал arrow только ради опшна тащить

он оборачивает же опшном

Option+ Try

ну вот такие штуки можно mayBeA flatMap { a -> mayBeB flatMap { b -> mayBeC map { c -> doSmth(a, b, c) } } }

конечно можно спокойно обойтись без Option

можно и без котлина обойтись и на жабе писать

ну вот такие штуки можно mayBeA flatMap { a -> mayBeB flatMap { b -> mayBeC map { c -> doSmth(a, b, c) } } }

Для такого проще определить let2-9

let2-9?

а

ну вариант, да

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

можно и без котлина обойтись и на жабе писать

Такое лучше всё таки на скалке писать ?

скоро, скоро :)

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

что по твоему должен делать get by lazy?

можно и без котлина обойтись и на жабе писать

Option в котлине - это куча лишнего кода и ненужные аллокации на обертку

опять же, смотря когда

где-то лишний, где-то не лишний

что по твоему должен делать get by lazy?

Будет тянуть данные откуда-то еще, обрабатывать их и выдавать наружу (это нужно один раз в приложении)

или ты хочешь сказать, что ничего из arrow.core.Option не может быть полезным впринципе?

Как и весь arrow. Это бессмысленный порт котов на язык, который не проектировался для этого (они бы еще на java портану)

Будет тянуть данные откуда-то еще, обрабатывать их и выдавать наружу (это нужно один раз в приложении)

тогда просто val foo by lazy = { //your awesome code}

https://kotlinlang.org/docs/reference/delegated-properties.html#lazy

Как и весь arrow. Это бессмысленный порт котов на язык, который не проектировался для этого (они бы еще на java портану)

тот же arrow-ский Try оооочень удобен

конечно можно обмазываться try-catch'ами

тот же arrow-ский Try оооочень удобен

а что он делает?

http://arrow-kt.io/docs/datatypes/try/

а что он делает?

Ну это MonadError<Id, Throwable>

а там композиции и вот это всё

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

ща как rxjava будет, кучу операторов учить и что-там когда должно вызываться, вместо старого доброго и прямого try-catch

ERROR: S client not available

есть еще всякие монады и прочее, но, во-первых, я понимаю это очень поверхностно, поэтому за это не буду говорить во-вторых, в arrow это ужасно документировано (почти никак)

ну не учи..)

ща как rxjava будет, кучу операторов учить и что-там когда должно вызываться, вместо старого доброго и прямого try-catch

Вам дорога в go, товарищ

тогда просто val foo by lazy = { //your awesome code}

В таком случае set нельзя задать для property

Для val его и так нельзя же

Вам дорога в go, товарищ

еще не добрался, но котлин по приятнее будет

Для val его и так нельзя же

От того и вопрос) Можно ли такие выкрутасы в котлине с Lazy

От того и вопрос) Можно ли такие выкрутасы в котлине с Lazy

у него внутри только get переопределен

у делегата.

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

если свой напишешь с set, то будет тебе лези для вара)

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

+

да, похоже, что ditch

Всю эту ditch можно безболезненно разрулить через field и можно обойтись без Lazy и setter остается.

oh boy

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

Думаю тебе надо сделать пета и все это там применить (прям с монад-трансформерами и может даже free-монадками), что бы разобраться. Я тоже когда-то пытался делать ридер монадки/either/option, но понял что в котлине это не практично.

ну пока в прод нормальну идут Try и Option'ы

особенно вкусно try с флетмапами всякими

oh boy

То ли еще будет) Давно на котлине кодишь?

когда работаешь с чтением/записью итд

То ли еще будет) Давно на котлине кодишь?

Я не особо про котлин, я тут в качестве диванного эксперта

особенно вкусно try с флетмапами всякими

А как ты “асинхроный” код делаешь?

там он не асинхронный

дао все возвращают try

и например у тебя сервис транзакционный

Те ты вообще не пишешь асинхронный код?

ну в том проекте, что на котлине, пока не писал

но использование arrow в проекте разве запрещает писать асинхронный код? =) К чему вопрос?)

асинхронный код в котлине пока годен только в отрыве от БД

но использование arrow в проекте разве запрещает писать асинхронный код? =) К чему вопрос?)

Ну если ты продолжишь для всего юзать arrow, то тебе придется жанглировать 2 и больше монадами одновременно. (интересно бы было бы посмотреть/послушать отзывы на такой котлин-код в реальном продакшене)

я бы сказал, в отрыве от любого IO