Comments / Profile of gnefedev / Habr

gnefedev Sep 4 2017 at 06:26

Кроме отсутсвия статической типизации, что не делает его Safe, что для меня является основным приемуществом языка

gnefedev Sep 4 2017 at 06:22

Согласен, не слишком удачный пример. В куске кода чуть выше (про репозиотрии) был более инетересный вариант (сейчас продублирую в статье). Это в случае, если класс писал не ты и T просто нет.

inline fun <reified T, ID: Serializable> CrudRepository<T, ID>.find(id: ID): T {
    return findOne(id) ?: throw ObjectNotFound(id, T::class.qualifiedName)
}

gnefedev Sep 3 2017 at 21:41

Может, это чопорно, но по мне Int не должен знать о ChronoUnit, Date и прочем. Написав такой extension, мы расширяем api Int такими знаниями.
Вариант ниже решает эту проблему: DAYS знает о Int, но не наоборот.

gnefedev Sep 3 2017 at 21:33

Тогда возвращаясь к локаничности, но без перегрузки примитивов. Я, навреное, на это перепишу свой код

val before = date - DAYS*3

gnefedev Sep 3 2017 at 21:29

Да, только IDE будет подсказывать все. Проверил

gnefedev Sep 3 2017 at 20:38

Тем, что первый нельзя заменять после инициализации. В случае с локальной переменной var нужен не часто, а вот в случае поля — вполне.

gnefedev Sep 3 2017 at 20:36

Мне не очень понравилась мысль перегружать примитивы. Это хорошо для DSL, но в продакшен коде будет приводить к проблемам, так как на days и months не остановишься, и скоро у простого Int будет api не меньше чем у list

-1

gnefedev Jul 26 2017 at 20:17

Почему я ненавижу Spring

Чем мощнее инструмент и чем больше он даёт возможностей, тем легче выстрелить себе в ногу. Так что либо ограничивайте способы применения, либо смиритесь.

gnefedev Jun 21 2017 at 12:17

Потому что это было бы единственной причиной учить gradle. При этом использование QueryDsl у меня совершенно естественным образом перетекло в другой модуль (работа с фронтом отделена и только там мне понадобилось). Итог: проблемы бы получил, а выгоду — нет.
Проект не старый, изначально писался на Kotlin. Но достаточно старый чтобы застать проблемы с совместимостью с Spring.

gnefedev Jun 20 2017 at 19:37

Дело не в локальной или не локальной val, а в том, лямбда это или нет. В данном случае поле — экземляр лямбды. Вот ещё вариант лямбды:

fun myFunc(x: Int) = {
    val y = 10
    x + y
}.invoke()

Это как run, только наоборот.

gnefedev Jun 20 2017 at 18:33

Ещё можно вот так))

val myFun: (Int) -> Int = {
    val y = 10
    it+y
}

fun use() {
    myFun(10)
}

Но это будет работать только при одном входном параметре

gnefedev Jun 20 2017 at 16:26

В этом случае Вам просто не нужен try. В Kotlin нет «checked» исключений.

gnefedev Jun 20 2017 at 16:23

Вы же, наверное, имели в виду генерацию Java-файлов annotation processor'ом из аннотаций в коде на Kotlin? Обычные исходники на Kotlin компилируются напрямую в байт-код, без трансляции в Java.

Да, аннотации в коде на Kotlin. Ещё раз уточню вопрос и поправлю статью

Тут можно сделать что-нибудь в духе

Я пробовал похожий вариант. В моем варианте поведение поля остается прерогативой поля, а не конструктора. Если таких полей несколько, а класс большой, то это начинает играть роль.

gnefedev Jun 20 2017 at 16:10

Согласен, проблема в головах. Но даже если просто везде, где нужно, добавить setter-getter, toString, equals и hashcode, которые мне достались бесплатно, то код разрастется где-то на треть.

gnefedev Jun 20 2017 at 16:03

К сожалению, Ваш пример не компилируется, не хватает catch:

fun myFunc(x: Int) = try {
    val y = 10
    x+y
} catch (e: Exception) {
    42
}

Зато можно не указывать, что возвращаете Int, компилятор и так об этом знает

gnefedev Jun 20 2017 at 15:54

Я, как-раз, пишу, что если выбирать не совсем корректное применение параметров по умолчанию, до добавление нового НЕ ЛОМАЕТ ничего, хотя по смыслу использования должно.

gnefedev Jun 20 2017 at 15:48

Ничуть не сомневаюсь. Но у меня maven, и переходить на gradle пока не собираюсь. В статье допишу вариант с переходом на gradle