LINUX.ORG.RU

История изменений

Исправление Legioner, (текущая версия) :

Ваш пример нарушает наименование getter-ов и setter-ов, в итоге во многие библиотеки, где идёт работа с getter-ами и setter-ами, костыли, чтобы работать с properties.

С records этот поезд уже ушёл и мнение разработчиков языка очевидно. Библиотеки надо будет дорабатывать, да. В принципе ничего не мешает какое-то время продублировать геттеры-сеттеры для этих библиотек. На самом деле, я так думаю, их не так уж и много, этих библиотек.

Так же ваш пример - это не синтаксический сахар, а новая сущность. Синтаксический сахар не отменяет старое написание, он его упрощает. Например, с появление лямбд, можно писать в старом стиле через анонимные классы, а можно в новом - через лямбды. И никакой разницы не будет.

С точки зрения языка геттеров-сеттеров как не было, так и нет. То, что там программисты придумали какие-то соглашения, к языку не относится. Ну и в современной Java уже нередко используется именно такое написание. Есть, конечно, стандарт Java Beans, но это всё же не язык, а внешняя нахлопка, да его и устаревшим уже можно считать, я так думаю, учитывая его игнорирование при дизайне records.

А вообще моё предложение никак не завязано на конкретное именование. Можно и через getXx/setXx называть. Я просто выбрал тот вариант, который в 2020 году взяли бы разработчики языка.

Вкусовщина. И два момента, в момент interop-а java/kotlin nullability да, возможно немного раздражает, т. к. со стороны java может прилететь что угодно и надо проверять (!! - плохая идея). Но если внутри pure kotlin постоянно натываемся на nullability, то тут уже вопросы к архитектуре.

То, что мне раздражает больше всего это код вида

class A {
    private var x: Int? = ...
    fun f() {
        if (x != null) {
            useX(x);
        }
    }

useX тут не скомпилируется (если он требует Int). Т.е. его инферренс не работает на поля класса. Мне нужно выносить это значение в локальную переменную или пользоваться уродскими конструкциями вроде x?.let { useX(it) } вместо красивого оператора if. Согласен, что вкусовщина, но для меня это важно. И такой код встречается слишком часто, чтобы я мог это игнорировать.

К тому же корутины скоро и в java заедут (project loom), вы и тогда будете отверждать, что они не нужны?

Мне не нужны. Но Project Loom это корутины на другом уровне. Для программиста вообще ничего не меняется, он как писал обычный код, так и пишет. Корутины будут работать на уровне библиотек, в том числе и на уровне уже давно написанного кода, который внезапно станет работать быстрей в некоторых случаях. Вот это действительно крутой инжиниринг. А переделывать под капотом корутины в state-машину это немного банально.

У kotlin отличная интеграция и ничего велосипедить нельзя, кроме @JvmStatic, @JvmOverloads. Сиквенсы опять же никто не заставляет использовать.

Что значит не заставляет? Так и про скалу можно сказать - стандартную библиотеку, мол, никто не заставляет использовать. На языке пишут так, как положено писать на этом языке.

Пишем бэк на kotlin в одном проекте, кладём на кроссплатформенность, т. к. JVM-only. Проблем не вижу.

Проблема в том, что усилия разработчиков уходят не туда, куда мне нужно. А усилия разработчиков Java уходят туда, куда мне нужно (ну не всегда туда, но хотя бы примерно в тот район).

Например?

Не использует invokedynamic для лямбд, например.

Нет конструкции try-with-resources.

Да, нет, можно сделать свою реализацию:

Ну такая реализация есть в стандартной библиотеке, её делать не надо. А как насчёт кода вида

try (OutputStream fileStream = Files.newOutputStream(Paths.get("circle.png"));
     OutputStream bufferedFileStream = new BufferedOutputStream(fileStream);
     ImageOutputStream imageOutputStream = new MemoryCacheImageOutputStream(bufferedFileStream)) {
    ImageIO.write(image, "PNG", imageOutputStream);
}

PS вот кстати мой код, который я юзаю для такого случая: https://discuss.kotlinlang.org/t/is-there-standard-way-to-use-multiple-resources/2613 но всё равно это не так удобно и надёжно, как в Java.

PSS я котлин не сильно ругаю, язык классный, просто не до конца классный.

Исходная версия Legioner, :

Ваш пример нарушает наименование getter-ов и setter-ов, в итоге во многие библиотеки, где идёт работа с getter-ами и setter-ами, костыли, чтобы работать с properties.

С records этот поезд уже ушёл и мнение разработчиков языка очевидно. Библиотеки надо будет дорабатывать, да. В принципе ничего не мешает какое-то время продублировать геттеры-сеттеры для этих библиотек. На самом деле, я так думаю, их не так уж и много, этих библиотек.

Так же ваш пример - это не синтаксический сахар, а новая сущность. Синтаксический сахар не отменяет старое написание, он его упрощает. Например, с появление лямбд, можно писать в старом стиле через анонимные классы, а можно в новом - через лямбды. И никакой разницы не будет.

С точки зрения языка геттеров-сеттеров как не было, так и нет. То, что там программисты придумали какие-то соглашения, к языку не относится. Ну и в современной Java уже нередко используется именно такое написание. Есть, конечно, стандарт Java Beans, но это всё же не язык, а внешняя нахлопка, да его и устаревшим уже можно считать, я так думаю, учитывая его игнорирование при дизайне records.

А вообще моё предложение никак не завязано на конкретное именование. Можно и через getXx/setXx называть. Я просто выбрал тот вариант, который в 2020 году взяли бы разработчики языка.

Вкусовщина. И два момента, в момент interop-а java/kotlin nullability да, возможно немного раздражает, т. к. со стороны java может прилететь что угодно и надо проверять (!! - плохая идея). Но если внутри pure kotlin постоянно натываемся на nullability, то тут уже вопросы к архитектуре.

То, что мне раздражает больше всего это код вида

class A {
    private var x: Int? = ...
    fun f() {
        if (x != null) {
            useX(x);
        }
    }

useX тут не скомпилируется (если он требует Int). Т.е. его инферренс не работает на поля класса. Мне нужно выносить это значение в локальную переменную или пользоваться уродскими конструкциями вроде x?.let { useX(it) } вместо красивого оператора if. Согласен, что вкусовщина, но для меня это важно. И такой код встречается слишком часто, чтобы я мог это игнорировать.

К тому же корутины скоро и в java заедут (project loom), вы и тогда будете отверждать, что они не нужны?

Мне не нужны. Но Project Loom это корутины на другом уровне. Для программиста вообще ничего не меняется, он как писал обычный код, так и пишет. Корутины будут работать на уровне библиотек, в том числе и на уровне уже давно написанного кода, который внезапно станет работать быстрей в некоторых случаях. Вот это действительно крутой инжиниринг. А переделывать под капотом корутины в state-машину это немного банально.

У kotlin отличная интеграция и ничего велосипедить нельзя, кроме @JvmStatic, @JvmOverloads. Сиквенсы опять же никто не заставляет использовать.

Что значит не заставляет? Так и про скалу можно сказать - стандартную библиотеку, мол, никто не заставляет использовать. На языке пишут так, как положено писать на этом языке.

Пишем бэк на kotlin в одном проекте, кладём на кроссплатформенность, т. к. JVM-only. Проблем не вижу.

Проблема в том, что усилия разработчиков уходят не туда, куда мне нужно. А усилия разработчиков Java уходят туда, куда мне нужно (ну не всегда туда, но хотя бы примерно в тот район).

Например?

Не использует invokedynamic для лямбд, например.

Нет конструкции try-with-resources.

Да, нет, можно сделать свою реализацию:

Ну такая реализация есть в стандартной библиотеке, её делать не надо. А как насчёт кода вида

try (OutputStream fileStream = Files.newOutputStream(Paths.get("circle.png"));
     OutputStream bufferedFileStream = new BufferedOutputStream(fileStream);
     ImageOutputStream imageOutputStream = new MemoryCacheImageOutputStream(bufferedFileStream)) {
    ImageIO.write(image, "PNG", imageOutputStream);
}

PS вот кстати мой код, который я юзаю для такого случая: https://discuss.kotlinlang.org/t/is-there-standard-way-to-use-multiple-resources/2613 но всё равно это не так удобно и надёжно, как в Java.