Избавляемся от библиотек сохранения состояния фрагмента с помощью чистого kotlin

[lukaville]

никакого рефлекшена

но delegated properties же используют рефлексию для получения kotlin.reflect.KProperty (соответственно еще появляется необходимость в зависимости org.jetbrains.kotlin:kotlin-reflect).

[Beholder]

Нет, делегатам достаточно сокращённой рефлексии, которая доступна через stdlib.

[KursoRUS]

kotlin.reflect.KProperty (а также KClass и остальные) лежат в kotlin stdlib, так что ничего подключать не надо. И если посмотреть декомпилированный код, то видно, что вся необходимая информация для создания KProperty, что используется в делегатах, встраивается в сгенерированный код.

static final KProperty[] $$delegatedProperties = new KProperty[]{(KProperty)Reflection.mutableProperty1(new MutablePropertyReference1Impl(Reflection.getOrCreateKotlinClass(TestFragment.class), "carName", "getCarName()Ljava/lang/String;")), (KProperty)Reflection.mutableProperty1(new MutablePropertyReference1Impl(Reflection.getOrCreateKotlinClass(TestFragment.class), "index", "getIndex()I"))};

[alexlitvinenko]

а эта зависимость приносит в проект еще около 9к методов)

[xkor]

KProperty хоть и лежит в пакете рефлексии не требует подключения соответствующей либы, по крайне мере если используется только поле name и если память не изменяет геттер и сеттер. Вот если захочется использовать поля returnType, parameters и т.п. то да, придется подключать либку с рефлексией на 2мегабайта...

[KuVa]

Добавлю, что свои делегаты лучше наследовать от котлиновских интерфейсов:

interface ReadOnlyProperty<in R, out T> {
    operator fun getValue(thisRef: R, property: KProperty<*>): T
}

interface ReadWriteProperty<in R, T> {
    operator fun getValue(thisRef: R, property: KProperty<*>): T
    operator fun setValue(thisRef: R, property: KProperty<*>, value: T)
}