Size: a a a

Kotlin Community

2020 October 14

IP

Iaroslav Postovalov in Kotlin Community
или как opt-in фича. но в своих проектах я их видеть не хочу
источник

IP

Iaroslav Postovalov in Kotlin Community
билдеры более прозрачные в плане того, какая структура там порождается. так что я мб готов только к rust-подобную синтаксису типа:
hashmap!{
 "k" => 1,
 "l" => 2,
}
источник

АО

Алексей Овсянников... in Kotlin Community
После вот этого сообщения я задумался, а сейчас нет никакой issue, которая предлагала бы что-то вроде:

fun example(
   someNullable: String? ?: return
) { ... }
источник

АО

Алексей Овсянников... in Kotlin Community
я просто не знаю, как это назвать, но такая штука реально нужна, когда сигнатуру менять нельзя (оверрайды всякие), но при этом внутри всё равно все параметры будут проверяться по каким-то правилам перед основной логикой
источник

с#

саша сок #KotlinGang... in Kotlin Community
Алексей Овсянников
я просто не знаю, как это назвать, но такая штука реально нужна, когда сигнатуру менять нельзя (оверрайды всякие), но при этом внутри всё равно все параметры будут проверяться по каким-то правилам перед основной логикой
fun example(
   someNullable: String?
) {
   someNullable ?: return
}
источник

с#

саша сок #KotlinGang... in Kotlin Community
не особо длиннее код
источник

АО

Алексей Овсянников... in Kotlin Community
Тем не менее, это проверка в теле:)
источник

с#

саша сок #KotlinGang... in Kotlin Community
Iaroslav Postovalov
билдеры более прозрачные в плане того, какая структура там порождается. так что я мб готов только к rust-подобную синтаксису типа:
hashmap!{
 "k" => 1,
 "l" => 2,
}
объясните мне, почему никому не нравятся распространенные везде штуки

[1, 2, 3]
{1: "test", 2: "test"}
источник

IP

Iaroslav Postovalov in Kotlin Community
саша сок #KotlinGang
объясните мне, почему никому не нравятся распространенные везде штуки

[1, 2, 3]
{1: "test", 2: "test"}
я готов принять первое, если оно выглядит как
list!{1, 2, 3} какой-нибудь - и возвращает конкретную структуру
и второе - по такому же принципу
источник

с#

саша сок #KotlinGang... in Kotlin Community
Iaroslav Postovalov
я готов принять первое, если оно выглядит как
list!{1, 2, 3} какой-нибудь - и возвращает конкретную структуру
и второе - по такому же принципу
хорошо. тогда можно просто сделать, чтобы ":" создавало Pair

listOf(1, 2, 3)  // это и щас норм
mapOf(
   3: "error_3",
   2: "error_2"
)
источник

IP

Iaroslav Postovalov in Kotlin Community
саша сок #KotlinGang
хорошо. тогда можно просто сделать, чтобы ":" создавало Pair

listOf(1, 2, 3)  // это и щас норм
mapOf(
   3: "error_3",
   2: "error_2"
)
не, если создавать литерал кортежей, то что делать с Triple?
источник

IP

Iaroslav Postovalov in Kotlin Community
саша сок #KotlinGang
хорошо. тогда можно просто сделать, чтобы ":" создавало Pair

listOf(1, 2, 3)  // это и щас норм
mapOf(
   3: "error_3",
   2: "error_2"
)
+это очень негибко будет, если нельзя будет для своих типов делать такую штуку
источник

с#

саша сок #KotlinGang... in Kotlin Community
ну да. в принципе со всем согласен
источник

IP

Iaroslav Postovalov in Kotlin Community
и это только очевидные подводные камни
источник

IP

Iaroslav Postovalov in Kotlin Community
спецы могут еще какую-нибудь несовместимость с грамматикой найти. или еще что-то нибудь
источник

IP

Iaroslav Postovalov in Kotlin Community
плюс вообще говоря это ничего не дает - максимум экономию одного символа
источник

D

Denys in Kotlin Community
Iaroslav Postovalov
плюс вообще говоря это ничего не дает - максимум экономию одного символа
И лучше читаемость. :)
источник

с#

саша сок #KotlinGang... in Kotlin Community
Denys
И лучше читаемость. :)
+. но очевидно, что надо это добавлять как-то по-другому
источник

D

Denys in Kotlin Community
Тут же вопрос не в том, что меньше или больше печатать, а в том, что есть некая привычная большинству семантика, которая позволяет уменьшить ментальную нагрузку при чтении кода.
источник

AN

Alexander Nozik in Kotlin Community
Denys
Тут же вопрос не в том, что меньше или больше печатать, а в том, что есть некая привычная большинству семантика, которая позволяет уменьшить ментальную нагрузку при чтении кода.
Ну я повторюсь. Я поначалу после груви сильно топил за литералы. Сейчас привык к тому, что они не нужны.
источник