Уверен. У вас есть коллекция, вы хотите получить первый элемент. В 99% случаев он существует и будет излишним возиться с проверкой на null.

после filter? java 8 streams всегда на такое отдают Optional

например

clojure выдаст null на пустой коллекции

а котлин просто упадет

после filter? java 8 streams всегда на такое отдают Optional

Если не ошибаюсь, filter вернёт пустую коллекцию, а first() выдаст экзепшен, если попытаться применить на пустой коллекции

Используйте firstOrNull()

Если не ошибаюсь, filter вернёт пустую коллекцию, а first() выдаст экзепшен, если попытаться применить на пустой коллекции

https://github.com/indrih17

https://github.com/indrih17

А причем тут мой гит?

ой

буфер глюкануло сорри)

Ничего.)

https://docs.oracle.com/javase/8/docs/api/java/util/stream/Stream.html#findFirst--

там правда тож возможен NPE - но first сработает как и ожидается - вернет что "может есть значение"

В котлине не принято использовать Optional.

просто ожидамое поведение совсем наоборот или first! или requiredFirst или что-то подобное

да, я скорее привел сравнение с другими языками

пытаюсь понять почему решили так а не иначе сделать

Потому что в 99% случаев это работает и first() что-то возвращает. Если он применен на пустой коллекции - значит где-то ошибка в логике программы, надо прямо об этом уведомить, а не скрывать за неопределенным поведением. А если у вас всё же по логике возможен пустой список - используйте firstOrNull().

Потому что в 99% случаев это работает и first() что-то возвращает. Если он применен на пустой коллекции - значит где-то ошибка в логике программы, надо прямо об этом уведомить, а не скрывать за неопределенным поведением. А если у вас всё же по логике возможен пустой список - используйте firstOrNull().

при этом в других языках так не посчитали - то есть получается вкусовщина

при этом в других языках так не посчитали - то есть получается вкусовщина

Ну, да.

Я тоже считаю, что это фиговое решение. Мне кажется first()!! better, than firstOrNull() everywhere

Разрабы котлина могли сделать first(), который может возвращать null, но это плохая практика. Везде придётся городить ?., хотя по логике там никак не может быть null.

могли сделать first!

и first который вернет T?

и first который вернет T?

firstOrNull() явно уведомляет о своем поведении.

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

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

С этим достаточно один раз столкнуться, чтобы понять и больше об этом не думать.

Всё будет на автомате.

Разрабы котлина могли сделать first(), который может возвращать null, но это плохая практика. Везде придётся городить ?., хотя по логике там никак не может быть null.

Если у тебя мапа, как ты можешь быть уверен, что там точно есть элемент по ключу?

У меня на автомате всегда писать firstOrNull(), тоже конечно решение. Ну апи уже сделано, обсуждать бессмысленно.

Если у тебя мапа, как ты можешь быть уверен, что там точно есть элемент по ключу?

Речь о том, что в одних ситуациях ты в этом не уверен и используешь .firstOrNull(), в других там должен быть этот элемент, а если его нету, то всё плохо и стоит в этом конкретном месте бросить исключение.

Да, в таком редком случае я бы сделал first()!! или редкую функцию с длинным названием типа firstNotNull()

Я вот не понимаю, откуда у людей столько придирок к мелочам вроде названий методов. Как в одном из интервью говорил Бреслав, "Раз единственное, что смущает людей в языке — это отсутствие тернарного оператора, значит всё остальное мы сделали правильно" :)

> в таком редком случае То, что вы любите null-ы больше, чем исключения, не значит, что так делают все.

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

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

Зато if else в = можно

А это реально удобно.

И не такие уже это мелочи, мелочи - это доступ к элементам массива через квадратные скобки.

Ну да, val x = if(a) b else c, несомненно, гораздо хуже, чем final int x = a ? b : c.

В Java кстати не хватает очень такого, когда if в =

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

Мы тут про стандартную либу говорили -)

Ну да, val x = if(a) b else c, несомненно, гораздо хуже, чем final int x = a ? b : c.

= if (currency.isEmpty()) "" else Currency.getInstance(currency).getSymbol(currencyLocale) = currency.isEmpty() ? "" : Currency.getInstance(currency).getSymbol(currencyLocale)

Лучше же читается

В чатике правда это не заметно -)

= if (currency.isEmpty()) "" else Currency.getInstance(currency).getSymbol(currencyLocale) = currency.isEmpty() ? "" : Currency.getInstance(currency).getSymbol(currencyLocale)

кстати про придирки

const val кажется тож совсем неочевидной наркоманией

сама по себе фраза

https://kotlinlang.org/docs/reference/keyword-reference.html#modifier-keywords Всё ради того, чтобы минимизировать количество hard keywords.

const val кажется тож совсем неочевидной наркоманией

Тут согласен.

Ну да, val x = if(a) b else c, несомненно, гораздо хуже, чем final int x = a ? b : c.

Вкусовщина. Лично мне - нет.

Вкусовщина. Лично мне - нет.

Это был сарказм — на мой взгляд, через некоторое довольно короткое время глаз перестаёт за это цепляться. Не говоря уже о том, что котлиновский if позволяет писать блоки вместо исключительно выражений, доступных в тернарнике.

Ну да, val x = if(a) b else c, несомненно, гораздо хуже, чем final int x = a ? b : c.

сарказм?

а, чёрт, не прочитал последнее сообщение)

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

Очевидность субьективна

Очевидность субьективна

Которую можно измерить скоростью понимания

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

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

++

Я вот немного на питоне писал, там x if predicate() else y конструкция. С виду безобидная, но если появляется вложенность, становится абсолютно нечитаемо. В Котлине же сделали идеально - "тернарный оператор" абсолютно равен синтаксически и семантически условному.

Пайтоновские list comprehensions вообще не от мира сего -- сейчас на нём пишу, хочу обратно на котлин :( if по их же мотивам вывернут, да.

про макросы)

Я готов перейти на го если в яве появятся макросы.

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

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

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

если для kotlin <-> kotlin, то есть https://github.com/Kotlin/kotlinx.serialization //cc @sandwwraith

Ну спринговый jackson из коробки прекрасно и с котлином работает

А для мультиплатформенных проектов да, надо kotlinx.serialization юзать

ок, спасибо

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

https://github.com/wizzardo/json-benchmarks

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

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

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

А чем Gson плох? Если нужны плюхи для Kotlin - есть Kotson.

у джексона есть стриминг апи и он довольно неплох. Для огромных json я его использую.

с помощью gson тоже можно читать в потоке

у джексона есть стриминг апи и он довольно неплох. Для огромных json я его использую.

Бойлерплейта много только, а так да

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

а зачем они вам там?)

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

Это не главная проблема голанга, лол