Удивительно, почему людям трудно затащить новую версию языка, но легко затащить новый язык. Ну про Андроид не говорим.
Кстати, у JetBrains есть инструментатор для NotNull-аннотаций, который тоже делает более понятные сообщения типа "java.lang.IllegalArgumentException: Argument 1 for NotNull parameter of Scratch.test must not be null".
Для локальных переменных аннотации не нужны, любая нормальная IDE и без них справится. А средство композиции есть. Называется if. Насчёт инициализации с Optional тоже бывает, что поле может иметь значение, может не иметь, но инициализировать его надо лениво. Как будем выкручиваться? Optional<Optional<X>>?
Конечно, если в целом окружающий код императивный, то лучше сделать if и return/break.
Ну то есть вы понимаете, что вопрос не в умении или не умении map/flatMap, а в том, какая у нас вообще задача и какой код вокруг? Просто вы так написали, будто готовы уволить любого, кто isPresent() в коде напишет.
ifPresent — это уныло. Мы можем находиться во вложенном if/while/for, тогда это не поможет. Если же у нас несколько проверок на null подряд, то будет opt1.ifPresent(x -> opt2.ifPresent(y -> opt3.ifPresent( -> {...}))). Ну и, конечно, замена if(opt.isPresent()) на opt.ifPresent() не делает код лучше в 99% случаев. Он не становится более функциональным, менее зависимым от сайд-эффектов, при этом его становится сложнее отлаживать в пошаговом отладчике, удлиняются стектрейсы и т. д.
Я вообще делаю обычно так:
V v = computeOptional().orElse(null);
if (v != null) {
... используем v
}
Некоторые приходят в ужас, но это самое удобное, что можно делать с optional.
Удивительно, что люди рассуждают о дизайне языков программирования, не зная этих языков программирования даже в самом минимальном объёме. Я на третьей лекции по Java для начинающих уже рассказываю, что присваивание в Java копирует ссылку, но никогда не копирует сам объект, потому что это никому не нужно и копирование объекта в Java в общем случае неразрешимая задача. Причём JIT-компилятор может и копирование ссылки соптимизировать (и сделает это практически всегда в данном сценарии кода, потому что нет причин так не делать).
Постоянно что-то ломается с каждым новым релизом Java или IDEA.
С этим должно стать лучше буквально со следующего релиза. Котлин-плагин затащили в репозиторий IntelliJ IDEA, соответственно он обновляться будет синхронно с основным кодом, интегрироваться только с конкретной версией Идеи, с которой поставляется, что упрощает разработку и тестирование. Ну и синхронные изменения в платформе и плагине делать проще будет. Плюс разработчики из Идеи будут чаще что-то исправлять в Котлин-плагине, если есть необходимость (например, чтобы избавиться от небезопасных устаревших вызовов). В общем, светлое будущее впереди :-)
Такие примеры появляются с завидной регулярностью (говорю про свою подсистему — язык Java). Вот буквально сегодняшнее. Пять лет назад пользователь попросил прокачать анализатор, чтобы он понимал, что метод интерфейса-аннотации никогда не возвращает null. Чтобы при сравнении с MyAnno.value() == null выдавалось Condition is always false. Изменение буквально пять строчек кода плюс тест. Очень просто. Мы сделали. Правда сам пользователь написал:
(technically, annotation.x() can be null, if someone implements FooBar annotation explicitly, but I guess nobody does it).
И вот на днях другой пользователь жалуется, что ему выдаётся ложное предупреждение, потому что "I guess nobody does it" реализуется в некотором фреймворке. А ложное предупреждение — это гораздо более неприятная ситуация, чем отсутствие правдивого предупреждения. Потому что пользователи верят предупреждениям и могут сломать себе код, удалив проверку, которую IDE пометила как ложная. Простой пример фичи, которую не надо было делать, несмотря на то что она простая.
Забавно, что относительно Котлина вы приводите конкретные цифры, названия компаний и ссылки и тут же бросаетесь голословным утверждением о стагнации Java последние 3-4 года без всяких подтверждений. Java сейчас очень бодро развивается.
Да, берём. И нам совершенно не стыдно. А что, где-то есть продуктовая компания, которая за 200 баксов вам все желания исполняет? Подскажите такую.
Не моя подсистема, не могу знать.
Кто-то выше утверждал, что Идея идеальный инструмент? Была бы она идеальна, мы бы без работы остались :-)
Последние пять лет Котлин-плагин не затаскивали в репозиторий IDEA. Поэтому вы не могли слышать подобных заявлений.
Нет, потому что в случае с Андроидом я с вами согласен. Там действительно без Котлина совсем тухло.
Удивительно, почему людям трудно затащить новую версию языка, но легко затащить новый язык. Ну про Андроид не говорим.
Кстати, у JetBrains есть инструментатор для NotNull-аннотаций, который тоже делает более понятные сообщения типа "java.lang.IllegalArgumentException: Argument 1 for NotNull parameter of Scratch.test must not be null".
На ифах будет плоская структура:
Не будет писаться, а уже пишется! Java 14 больше года назад вышла =)
Это вы перечислили проблемы, которые по вашим словам "технически можно исправить довольно быстро"?
Для локальных переменных аннотации не нужны, любая нормальная IDE и без них справится. А средство композиции есть. Называется
if. Насчёт инициализации с Optional тоже бывает, что поле может иметь значение, может не иметь, но инициализировать его надо лениво. Как будем выкручиваться?Optional<Optional<X>>?Ну то есть вы понимаете, что вопрос не в умении или не умении map/flatMap, а в том, какая у нас вообще задача и какой код вокруг? Просто вы так написали, будто готовы уволить любого, кто isPresent() в коде напишет.
ifPresent — это уныло. Мы можем находиться во вложенном if/while/for, тогда это не поможет. Если же у нас несколько проверок на null подряд, то будет opt1.ifPresent(x -> opt2.ifPresent(y -> opt3.ifPresent( -> {...}))). Ну и, конечно, замена
if(opt.isPresent())наopt.ifPresent()не делает код лучше в 99% случаев. Он не становится более функциональным, менее зависимым от сайд-эффектов, при этом его становится сложнее отлаживать в пошаговом отладчике, удлиняются стектрейсы и т. д.Я вообще делаю обычно так:
Некоторые приходят в ужас, но это самое удобное, что можно делать с optional.
Вот я даже картинки из лекций нашёл, где показано, что при присваивании мы ссылаемся на тот же объект и можем его поменять:
Удивительно, что люди рассуждают о дизайне языков программирования, не зная этих языков программирования даже в самом минимальном объёме. Я на третьей лекции по Java для начинающих уже рассказываю, что присваивание в Java копирует ссылку, но никогда не копирует сам объект, потому что это никому не нужно и копирование объекта в Java в общем случае неразрешимая задача. Причём JIT-компилятор может и копирование ссылки соптимизировать (и сделает это практически всегда в данном сценарии кода, потому что нет причин так не делать).
Локальная переменная.
С этим должно стать лучше буквально со следующего релиза. Котлин-плагин затащили в репозиторий IntelliJ IDEA, соответственно он обновляться будет синхронно с основным кодом, интегрироваться только с конкретной версией Идеи, с которой поставляется, что упрощает разработку и тестирование. Ну и синхронные изменения в платформе и плагине делать проще будет. Плюс разработчики из Идеи будут чаще что-то исправлять в Котлин-плагине, если есть необходимость (например, чтобы избавиться от небезопасных устаревших вызовов). В общем, светлое будущее впереди :-)
Интересно, вы это вручную делаете или какие-то инструменты есть, которые преобразуют Котлин в Джаву?
Какого экземпляра класса? Вы о чём? Никаких экземпляров не создавалось ни до, ни после.
Такие примеры появляются с завидной регулярностью (говорю про свою подсистему — язык Java). Вот буквально сегодняшнее. Пять лет назад пользователь попросил прокачать анализатор, чтобы он понимал, что метод интерфейса-аннотации никогда не возвращает
null. Чтобы при сравнении сMyAnno.value() == nullвыдавалось Condition is always false. Изменение буквально пять строчек кода плюс тест. Очень просто. Мы сделали. Правда сам пользователь написал:И вот на днях другой пользователь жалуется, что ему выдаётся ложное предупреждение, потому что "I guess nobody does it" реализуется в некотором фреймворке. А ложное предупреждение — это гораздо более неприятная ситуация, чем отсутствие правдивого предупреждения. Потому что пользователи верят предупреждениям и могут сломать себе код, удалив проверку, которую IDE пометила как ложная. Простой пример фичи, которую не надо было делать, несмотря на то что она простая.
Забавно видеть, что каждый комментатор живёт в своём пузыре. У вас вот вселенная, где весь бэкэнд на Го.
Забавно, что относительно Котлина вы приводите конкретные цифры, названия компаний и ссылки и тут же бросаетесь голословным утверждением о стагнации Java последние 3-4 года без всяких подтверждений. Java сейчас очень бодро развивается.
3-4 года? Это мелочи. Есть тикеты, которые по 15 лет висят!
Бывает так, что технически исправить просто, но не нужно.