fun <T, U, R> ifBothNotNull(t: T?, u: U?, code: (T, U)->R): R? { return if (t != null && u != null) code(t, u) else null }

?.let не масштабируется, val a= this.a выглядит избыточно и не красиво. а применять где-то одно, а где-то другое еще и не консистентно =))

https://discuss.kotlinlang.org/t/kotlin-null-check-for-multiple-nullable-vars/1946/4

fun <T, U, R> ifBothNotNull(t: T?, u: U?, code: (T, U)->R): R? { return if (t != null && u != null) code(t, u) else null }

неплохо =), но else надо отдельно передавать и выглядеть это будет странно

ну такое, if (t != null && u != null) выглядит куда читабельнее так ли уж избыточно val a = this.a если взять во внимание что идет обращение к геттеру? т.е. стоит ли оно того?

неплохо =), но else надо отдельно передавать и выглядеть это будет странно

Что значит "отдельно передавать"?

Что значит "отдельно передавать"?

отдельным параметром

иначе куда его деть?

Код для else?

дело не в тредах, оно и в 1м треде может измениться а как писать, пример уже был, не все же let -ом единым

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

там же возвращается null, т.е. ?: else-operation

Код для else?

да

во-первых, можно использовать ?:. Во-вторых, я часто для функторов типа Option объявляю функцию которая принимает две лямбды, это вроде тоже норм.

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

кастомный геттер

кастомный геттер

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

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

Это детали реализации, которые могут меняться от версии к версии кода.

во-первых, можно использовать ?:. Во-вторых, я часто для функторов типа Option объявляю функцию которая принимает две лямбды, это вроде тоже норм.

ну то есть простое и лаконичное } else { превращается в } ?: run { мне одному это кажется не оч?

Это детали реализации, которые могут меняться от версии к версии кода.

да, тогда согласен

+ он может быть, но не изменять значение, а может и изменять. И выйдет что сегодня нельзя, завтра можно и опять по новой код переделывать

+ он может быть, но не изменять значение, а может и изменять. И выйдет что сегодня нельзя, завтра можно и опять по новой код переделывать

да, спасибо за новое понимание

во-первых, можно использовать ?:. Во-вторых, я часто для функторов типа Option объявляю функцию которая принимает две лямбды, это вроде тоже норм.

а почему Option ты называешь функтором?

да точно

в этом же чатике вроде как был чел который лямбды называл функторами

а почему Option ты называешь функтором?

что в твоём мире означает слово функтор (только нельзя отвечать "абстракция")

а почему Option ты называешь функтором?

Потому что Option — функтор, в т. ч. аппликативный, и монада :)

https://medium.com/@aballano/kotlin-functors-applicatives-and-monads-in-pictures-part-1-3-c47a1b1ce251

Потому что Option — функтор, в т. ч. аппликативный, и монада :)

хороший ответ получился "функтор - потому что функтор", а что делает его функтором?

лол

хороший ответ получился "функтор - потому что функтор", а что делает его функтором?

способность применить функцию к значению, завёрнутому в него

не ну там нужно отвечать что он функтор в контексте функции map (не уверен что в котлине это так) и показать что законы функтора работают для этой функции и этого типа

не ну там нужно отвечать что он функтор в контексте функции map (не уверен что в котлине это так) и показать что законы функтора работают для этой функции и этого типа

В Котлине это так, как напишешь, потому что в stdlib нет Option.

но этим уже кто-нибудь занимался и скорей всего да есть такая функция и да всё работает (ну не прям строго - всё таки нулы могут в нём появится)

аа вы не про знак вопроса, а про option из джавы?

аа вы не про знак вопроса, а про option из джавы?

В Джаве он Optional, и я его не использую, т. к. он из восьмой версии =)

Я про сферический Option в вакууме.

ну ок, тогда точно всё работает

а как знание аби коррелирует со знаниями котлина? )

По-твоему, нормально заявлять знание Котлина, не зная основы ведра?

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

А котлин это язык разработки под ведро?

способность применить функцию к значению, завёрнутому в него

?

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

По-твоему, нормально заявлять знание Котлина, не зная основы ведра?

Причем тут ведро, если он на JVM в целом

А котлин это язык разработки под ведро?

Фактически да

Больше нигде особой популярности пока не получил

Только у молодежи

Мы про язык или про популярность?

Больше нигде особой популярности пока не получил

JetBrains заявляет только 50 процентов пользователей с андроида - остальные большая Java

Как можно кодить на котлине под большую джаву не зная основ ведра?

JetBrains заявляет только 50 процентов пользователей с андроида - остальные большая Java

Не вижу что-то

Не вижу что-то

а, ну тогда ок

Не вижу что-то

я думаю им все-таки виднее =)

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

Но которые все равно используют на ведре

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

да-да, обман, чтобы классы набрать

как можно кодить на джаве не зная основ ведра

как можно кодить на свифте не зная основ иос

ладно кажись у меня иссякает фантазия. какие там ещё бывают производные языки

для тайпскрипт - какие там нужно основы знать?

С пеной у рта доказывают плюсы Котлина, но не знают про аби :)

Набросил так набросил

Набросил так набросил

Где набросил?

вот кстати интересный вариант https://github.com/importre/kotlin-unwrap/blob/87a8b4cf2492fbac6c141766410a955f13d6138d/src/main/kotlin/com/importre/unwrap/Unwrap.kt

для работы c nullable

unwrap(_a, _b, _c) { a, b, c -> println("$a, $b$c") // not invoked } otherwise { println("Nah!") // invoked because `_c` is null }

слово otherwise здесь удобно

но жаль для этого алоцировать объект каждый раз

да, в котлине не помешали бы инлайн-классы

ERROR: S client not available

но жаль для этого алоцировать объект каждый раз

да ну нафиг, лучше лишние круглые скобки написать

да ну нафиг, лучше лишние круглые скобки написать

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

Хороши набрасывать сами. Я говорю о своём опыте -- ко мне идут собеситься​ на ведро чуваки, которые не знаю ведро, но знают Кокококотлин.

Если бы собесил на ЖВМ, было бы то же самое. Или не было бы. Я про ведро пишу тут.

И чё?)

И да, они должны знать ведро, прежде чем кококотлинять. И ЖВМ. Один мне так доказывал, а потом спросил, что такое GC.

Кокококотлин это глупо.

Я в метро ехал, палец соскользнул

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

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

Так, стоп.

О какой конкретно корреляции сейчас речь?

Между чем?

ну и как там знание гц сильно помогает?

А зачем вы собеседуете людей которые не знают что такое ГЦ

Вы всех подряд с улицы собираете?

Именно то не собеседованием было, а беседой -- примерно​как как сейчас.

Только тех, кто знает котлин

На собеседования берем как обычно

Выборка не один человек, а человек 20

Из них только один товарищ оказался компетентным.

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

есть такие вещи которые легче понять в котлине чем в джаве?

А вывод из этого какой следует? Язык должен быть сложным?

есть такие вещи которые легче понять в котлине чем в джаве?

Котлин больше похож на JavaScript, так что он в какой-то степени проще.)

А вывод из этого какой следует? Язык должен быть сложным?

Вывод — инструменты нужно знать.

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

Что мешает использовать котлин и учить ведро одновременно?

Котлин больше похож на JavaScript, так что он в какой-то степени проще.)

ну такое. с типами вроде посложнее. ну разве что то что типы можно не писать лишний раз.

Чем это отличается от использования джавы и изучению ведра?

А вывод из этого какой следует? Язык должен быть сложным?

Вывод сообщением выше.

Ну и квантум правильно написал.

Хороши набрасывать сами. Я говорю о своём опыте -- ко мне идут собеситься​ на ведро чуваки, которые не знаю ведро, но знают Кокококотлин.

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