Comments 28
Проблема в том, что Kotlin компилируется в JavaВы же, наверное, имели в виду генерацию Java-файлов annotation processor'ом из аннотаций в коде на Kotlin? Обычные исходники на Kotlin компилируются напрямую в байт-код, без трансляции в Java.
<...> если мы используем переданный в конструктор параметр, то он будет присвоен полю сразу, минуя переопределенный setterТут можно сделать что-нибудь в духе
class User(nameParam: String) {
var name: String = ""
set(value) { field = value.toUpperCase() }
init { name = nameParam } // вызовется сеттер
}
Лямбда, вложенная в лямбдуПро такое, кстати, даже в документации (coding conventions) сказано, что если лямбды вложены, то у всех лучше явно писать все параметры вместо использования
it.
Вы же, наверное, имели в виду генерацию Java-файлов annotation processor'ом из аннотаций в коде на Kotlin? Обычные исходники на Kotlin компилируются напрямую в байт-код, без трансляции в Java.
Да, аннотации в коде на Kotlin. Ещё раз уточню вопрос и поправлю статью
Тут можно сделать что-нибудь в духе
Я пробовал похожий вариант. В моем варианте поведение поля остается прерогативой поля, а не конструктора. Если таких полей несколько, а класс большой, то это начинает играть роль.
- Код, понятный только посвященным
Очень хорошо ложится, кстати, если не знать java при изучении kotlin (в моём случае — scala).
Типичная "функциональщина".
Лаконичность кода на языке K это не столько свойство языка K, сколько умение программиста четко и ясно выражать свои мысли вне зависимости от языка. Даже на Java можно писать коротко и понятно (если уметь). А если дать правильному джависту в руки C...
В последнее время читаю очень много кода на Kotlin. И скажу вам, Котлин, там где я его вижу ни разу не лаконичен. Почему? А потому что пишут на нем как на Java. С таким же страшным форматированием. И Scala не лаконична в неправильных руках. Так что если говорить о преимуществах и недостатках. Да, получается короче, но не очень. И не факт, что те 8500 строк которые вы имеете в проекте, нельзя приравнять к 8500 строкам кода на Java.
2_&{&/x!/:2_!x}'!R
То есть можно написать
fun muFunc(x: Int): Int = try {
val y = ...
x+y
}
и не мучиться с return?
Мне этот язык становится интересен.
fun myFunc(x: Int) = try {
val y = 10
x+y
} catch (e: Exception) {
42
}
Зато можно не указывать, что возвращаете Int, компилятор и так об этом знает
val myFun: (Int) -> Int = {
val y = 10
it+y
}
fun use() {
myFun(10)
}
Но это будет работать только при одном входном параметре
В scala в этом месте return так же не нужен.
fn add_2(x: i32) -> i32 { x + 2 }
Если вы используете параметры по умолчанию, и общее количество параметров достаточно большое, то лучше делать вызовы с именованными параметрами там, где метод/функция была использована. Тогда добавление новых параметров ничего не ломает.
1. Пожалуйста, убедитесь, что используете последнюю версию Kotlin Gradle Plugin и ‘kotlin-kapt’-плагина (https://kotlinlang.org/docs/reference/kapt.html);
2. Я добавил пример с QueryDsl в наш репозиторий с примерами (https://github.com/JetBrains/kotlin-examples/tree/master/gradle/kotlin-querydsl). Надеюсь, он поможет;
3. Не бойтесь публиковать ишью в наш баг-трекер (http://kotl.in/issue). Даже если то, с чем вы столкнулись, на самом деле не баг, мы постараемся вам помочь.
Можете написать по какой причине? Предположу, что это "старый" проект, который продолжили писать на Kotlin.
1) Отсутствие нужных плагинов либо их недостаточно хорошая работа в Gradle. Как пример — при запуске JUnit тестов простым образом нельзя подсунуть Listener. Это аффектит работу Allure и либо требует некоторых и доработок, которые могут ломать привычные имеющиеся наработки.
2) Отсутствие специалистов. В любой технологии нужно разобраться. Если проект сложнее стандартного — доработать технологию под себя.
3) Боязнь Gradle из-за его некоторой нестабильности. Смена API для плагинов как пример(да, лично нарывался на ситуацию, когда это что то сильно аффектило). Другой пример — смена языка написания build-скриптов(Hello Kotlin!).
Проект не старый, изначально писался на Kotlin. Но достаточно старый чтобы застать проблемы с совместимостью с Spring.
По поводу пункта 5 — на мой взгляд, код получился достаточно понятным. А вот что в Котлине действительно выносит мозг, на мой взгляд, даже сильнее имплиситов в Scala, так это неявный this в лямбдах, через который делаются билдеры и прочие DSLи. Из-за него внутри лямбды магическим образом становится возможно вызывать методы, которые определены на типе receiver'а, и откуда эти методы берутся в конкретном куске кода, без дополнительного исследования понять нельзя. В Scala, например, через имплиситы нельзя добавить новые методы непосредственно в область видимости; новые методы могут быть добавлены только к какому-нибудь объекту (через имплиситные классы).
Понятно, что и в том и в другом случае при наличии IDE найти, откуда берется какой-то метод, не составляет особой сложности, но лично мое ИМХО — понять код с имплиситами в Скале проще, чем код с переопределенным this для лямбд в Котлине. Кроме того, синтаксическая привязанность неявно добавленных методов к объекту упрощает чтение — код в Котлине был бы существенно понятнее, хоть и существенно многословнее, если бы для вызова методов на this необходимо было бы всегда писать this явно.
Послевкусие от Kotlin, часть 1