Комментарии 7
Давайте вместо простого и понятного вызова конструктора родим дополнительную абстракцию с генериками и поржем над нубасами, которые пытаются въехать в проект. То, что язык дает такие возможности это прекрасно, но не забывайте про бритву. Подберите более релевантный пример, пожалуйста :)
Мой реальный кейс, где я впервые применил механизм, вам бы понравился.
Был у меня тест с таким сценарием:
1 - создаем N ссылок на файлы
2 - раскладываем ссылки в специальную структуру
3 - применяем команду к структуре
4 - проверяем, как структура изменилась
Свойства ссылки в рамках структуры зависит места, которое она занимает в структуре, но при этом сама ссылка никакой информации о своем месте не содержит (и не должна).
Ссылок много. Ну и в целом тест оказался не очень простой - код занял полтора экрана.
Для упрощения читаемости теста имена переменных ссылок на файлы я сделал говорящими. Но этого оказалось мало, т.к. при дебаге в дебрях тестируемого кода имена исходных переменных уже недоступны. Поэтому я продублировал имя переменной в поле ссылки вручную, а потом и придумал, как это делать автоматически.
Но это очень специфический случай, вникать в него вряд ли интересно. Поэтому я привел вырожденный пример чтоб проиллюстрировать механизм. В каких реальных случаях его стоит применять - то личное дело каждого. )
Но только упаси вас бог переименовать такую переменную при "незначительном" рефакторинге.
Было:
val red by color()
Захотели ясности:
val foregroundColor by color() // было "red"
Думаю наиболее полезно было бы при работе с БД, где из имени свойства можно было бы по умолчанию выводить имя колонки
Не соглашусь.
Допустим, мы зачем-то решили сами написать компонент, который генерит SQL или мапит ResultSet.
Тогда проще взять имена полей более традиционным способом, примерно так:
data class SomeEntity(val prop1: String, val prop2: Int)
val properties = SomeEntity::class.declaredMemberProperties
val someEntity = SomeEntity(prop1 = "Hello", prop2 = 100500)
properties.forEach { prop ->
println(prop.name + " = " + prop.get(someEntity))
}
// ==>
//prop1 = Hello
//prop2 = 100500
Ох, не дай бог в реальности такое встретить. Имя переменной влияет на поведение программы, это даже круче классики
#define TRUE FALSE // счастливой отладки суки
Но для ненормального программирования была бы хорошая статья, возможность языка интересная.
Kotlin — ещё меньше копипасты с делегатами локальных переменных