В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

Kotlin Community

4125 membersпожаловаться на группу
2021 January 06

AL

Alexander Levin in Kotlin Community
В случае invocationOnMock это конечно в рантайме проверяется, что вы действительно такие параметры передали (но нормально проверяется из-за reified generics переданных)

Ну и наверное ключевой момент - если у вас прямо хорошо структура известна на момент компиляции - это тогда наверное уже не про вызов get(String) или get(Int), это как раз про использование пропертей напрямую
источник
17:27пожаловаться#1

AL

Alexander Levin in Kotlin Community
fallback до get(String) и get(Int) я предлагал выше скорее как фолбек. Да, не всегда это безопасно на этапе компиляции, но иногда это хороший компромис.

Пример - в случае фолбека до get(Int) в библиотеке больше не нужны будут component1-5 для листов (которые тоже небезопасны)
источник
17:28пожаловаться#2

DK

Denis Kalinochkin in Kotlin Community
У листа хотя бы тип известен
источник
17:29пожаловаться#3

AL

Alexander Levin in Kotlin Community
*но также никто не отменяет, что get(String) или get(Int) может возвращать какой-то безопасный тип (например nullable), если это уместно
источник
17:29пожаловаться#4

RI

Ruslan Ibragimov in Kotlin Community
Мне кажется вы рассматриваете два разных юзкейса деструкторизации. Одна когда мы знаем тип который дескруктиризируем (class, data class, generic с bound), и когда деструкторизация неизвестного типа или контейнера. В первом случае через использование констант можно добиться компайл-тайм сейфити. Во втором – нет, но там и не нужно
источник
17:29пожаловаться#5

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
Мне кажется вы рассматриваете два разных юзкейса деструкторизации. Одна когда мы знаем тип который дескруктиризируем (class, data class, generic с bound), и когда деструкторизация неизвестного типа или контейнера. В первом случае через использование констант можно добиться компайл-тайм сейфити. Во втором – нет, но там и не нужно
Про динамику вообще вроде как не говорили. Это отдельная штука и с ней во многом все проще. Легко все сделать на библиотечном уровне. Речь была только про компайл-тайм деструктуризацию
источник
17:30пожаловаться#6

RI

Ruslan Ibragimov in Kotlin Community
Должна быть возможость просто выразить явно ожидаете ли вы что в (условной) мапе будет такой ключ с таким типом, или нет. И в зависимости от этого получить null или эксепшен

val { foo : String? } = map // maybe foo
val { foo: Int } = map // foo int exists, or exception
источник
17:31пожаловаться#7

DK

Denis Kalinochkin in Kotlin Community
val { key } ?= map
val { key } !!= map
источник
17:32пожаловаться#8

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
Должна быть возможость просто выразить явно ожидаете ли вы что в (условной) мапе будет такой ключ с таким типом, или нет. И в зависимости от этого получить null или эксепшен

val { foo : String? } = map // maybe foo
val { foo: Int } = map // foo int exists, or exception
Так это уже есть через делегаты. Чего изобретать-то?
источник
17:32пожаловаться#9

AN

Alexander Nozik in Kotlin Community
И давайте все-таки разделять термины. Это не деструктуризация никакая. Это динамический разбор обычный.
источник
17:33пожаловаться#10

RI

Ruslan Ibragimov in Kotlin Community
Alexander Nozik
Так это уже есть через делегаты. Чего изобретать-то?
Ну например так:

val { foo: String, bar: Int } = map


или вот так:

val { foo: String, …rest: Map<K, V> } = map


через делегаты не получится
источник
17:33пожаловаться#11

AL

Alexander Levin in Kotlin Community
Alexander Nozik
И давайте все-таки разделять термины. Это не деструктуризация никакая. Это динамический разбор обычный.
Так у вас и сейчас просто динамический разбор позиций внутри круглых скобок до вызовов componentN, который никак не гарантируется компилятором, что будет безопасен.
источник
17:34пожаловаться#12

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
Ну например так:

val { foo: String, bar: Int } = map


или вот так:

val { foo: String, …rest: Map<K, V> } = map


через делегаты не получится
получится. В две строки. Не понятно, что тут экономится
источник
17:34пожаловаться#13

AL

Alexander Levin in Kotlin Community
Компилятором разве что сейчас гарантируется, что он для дата классов нужное количество componentN сгенерит
источник
17:34пожаловаться#14

AN

Alexander Nozik in Kotlin Community
Alexander Levin
Так у вас и сейчас просто динамический разбор позиций внутри круглых скобок до вызовов componentN, который никак не гарантируется компилятором, что будет безопасен.
Еще раз, я вообще не говорил про листы. Я говорил исключительно про типо-безопасный разбор.
источник
17:35пожаловаться#15

AN

Alexander Nozik in Kotlin Community
Alexander Levin
Компилятором разве что сейчас гарантируется, что он для дата классов нужное количество componentN сгенерит
Нужное количество нужных типов
источник
17:35пожаловаться#16

RI

Ruslan Ibragimov in Kotlin Community
Alexander Nozik
получится. В две строки. Не понятно, что тут экономится
Нет, by map это get<T>, тут это еще и манипуляция с остатком map. Можно достать N значений, а остальное прокинуть ниже (в компонент например child)
источник
17:36пожаловаться#17

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
Нет, by map это get<T>, тут это еще и манипуляция с остатком map. Можно достать N значений, а остальное прокинуть ниже (в компонент например child)
Ну тоже не сложно сделать на уровне библиотеки, я правда не знаю, случая, где это реально надо было бы - именно отщеплять поля по одному
источник
17:36пожаловаться#18

RI

Ruslan Ibragimov in Kotlin Community
Alexander Nozik
Ну тоже не сложно сделать на уровне библиотеки, я правда не знаю, случая, где это реально надо было бы - именно отщеплять поля по одному
React типичный
источник
17:37пожаловаться#19

AN

Alexander Nozik in Kotlin Community
Ruslan Ibragimov
React типичный
Я уже говорил, что я хочу его выкинуть? Это опять же нужно только в том случае, если мы все структуры разбираем путем прохода по ним. Мы почти никогда не делаем это в котлин, хотя сплошь и рядом делаем в JS (там других вариантов нет). В котлин мы обращаемся по имени поля. Это значит, что отщеплять ничего не надо
источник
17:38пожаловаться#20