а зачем он там?
А зачем он в KClass? Простейшее объяснение - копировали c Java
Например, чтобы при передаче его в метод, автоматом определялся и проверялся дженерик метода
Для примера com.google.common.reflect.TypeToken вполне себе дженерик. На ум приходит то что в джаве способы получения Type всегда были нетипизированные: SomeClass.class .getDeclaredField(“someField”) .getGenericType(); И поэтому большой пользы в этом не было. В Kotlin есть typeOf() который удобно было бы использовать с дженериками, я даже для этого обертки делал: public inline class GenericType<T : Any>( public val actual: KType ) public inline fun <reified T : Any> type(): GenericType<T> { return GenericType(typeOf<T>()) } internal interface Komodo { suspend fun <T : EntryPoint<R>, R> run(source: String, type: GenericType<T>): R } Было удобно и красиво. Выглядит как просчет в дизайне. Не подумали про typeOf
Я просто переехал почти везде с KClass на KType и невозможность прокинуть его вместе с дженериком напрягает
Решение интересное, возможно утащу
Скопировали с джавы, а там нельзя дженерик, потому что примитивы.
ну как, у KClass есть же
Ну значит у них по какой-то другой причине нельзя.
Я думаю, что Руслан прав и просто недодизай
Возможно, надо было просто отдельный тип для typeOf сделать.
https://youtrack.jetbrains.com/issue/KT-50702
Кажется, это надо было обсуждать до того, как он перестал быть эксперементальным
Ну то, решение, которое я написал, ничего не ломает
https://github.com/mipt-npm/tables-kt/blob/4912afde00feec85f50eec2315e8f61cc94bde4f/src/commonMain/kotlin/space/kscience/tables/ColumnHeader.kt#L58 у меня не открывается
упсь. Я похоже линк с рефактор ветки дал, сейчас починю
починил, спасибо. Но пример @frostbit еще лучше
Если не секрет, какие задачи требуют прям такой работы с типами? У меня на ум только плагины приходят
Там в ишшью всё рассказали. Например колонки таблиц
Обсуждают сегодня