Ну теоретически можно сделать контекстно-зависимое ключевое слово open, которое является ключевым только в списке модификаторов. Собственно, слово sealed так и добавлено: вы спокойно можете иметь метод sealed или переменную sealed.
Чего ж ты не написал свои гениальные идеи в мейлинг-лист? :-) Кстати, ещё не поздно: фича не финализирована, ключевое слово вполне можно поменять. Иди в amber-spec-comments и предлагай! На Хабре-то тебя Брайан не прочитает :-)
Всё просто. Shape — это интерфейс. Рекорды могут реализовывать интерфейсы. Есть у него точка в виде поля или нету — никого волновать не должно. Квадрат может быть удобно задать центром и длиной стороны, а может быть углом и длиной стороны. В одном из случаев метод, который возвращает центральную точку, не будет тривиальным геттером, а будет вычислять значение. Должна быть возможность тривиальным образом сменить одну реализацию на другую, не сломав ни одного клиента. Абстракция! Рекорд по определению имеет прозрачную структуру, он не обеспечивает абстракции.
Это и называется flow typing. И в Java он не реализован и не будет. Об этом я и говорю. Вместо этого в джаве вводится новая переменная — такого синтаксиса в Котлине нет.
К сожалению, старая школа ООП вбила этот ужасный паттерн наследования реализаций. Наследование — это специализация. Совершенно очевидно, что точка в трёхмерном пространстве не является специальным случаем точки в двумерном пространстве. В таком наследовании нет смысла.
Возможность наследования убила бы инварианты рекордов. Например, совершенно непонятно как правильно автоматически сгенерировать equals для рекорда, если его можно наследовать. Ломбок не заморачивается семантикой и дизайном языка, он просто пихает фичи. Ломбок как раз является синтаксическим сахаром в отличие от рекордов, которые несут семантическую нагрузку.
Это не стандарт, а соглашение. Стандарт говорит "Accessor methods can have arbitrary names" (JavaBeans 1.01a, 7.1). В разделе 8.3 действительно описывается именование на get/is, но в разделе 8.2 ещё раз подчёркивается "However, within Java Beans the use of method and type names that match design patterns is entirely optional".
Фреймворки и утилиты не так уж сильно уже завязаны на него и могут адаптироваться. К примеру, Jackson давно адаптировался.
На мой взгляд, это слишком легкомысленное замечание. Во-первых, речь не только о сахаре. Например, рекорды — это модельная сущность, nominal tuple, тип-произведение, если хотите. Это штука с сильной семантикой, а не просто синтаксический шорткат. Во-вторых, "взяли из Котлина" — это просто неверно. Синтаксически эти штуки непохожи на Котлин, а, например, instanceof patterns вообще в Котлине прямого аналога не имеют. У Котлина иной путь — flow typing, который в Java никто тащить не собирается. Sealed types — это больше не фича языка Java, а фича виртуальной машины: проверка иерархии делается на уровне VM, и там надо было аккуратно поработать с раздельной компиляцией и т. д. И теперь как раз котлиновские sealed-типы адаптируют, чтобы они были sealed-типами на уровне JVM. И, кстати, sealed-интерфейсов в Котлине не было, и теперь их затаскивают в Котлин из Java. Тоже берут сахар? Даже текстовые блоки синтаксически похожи совсем не на Котлин (где они плохо сделаны), а на Swift. За каждой из этих фич годы исследований и дизайна, а не просто "давайте сделаем как в языке X".
Обратите внимание, что методы чтения именуются не стандартным для Java способом.
Хм. String.length(), Collection.size(), Process.pid(), Process.exitValue(), Runtime.availableProcessors(), Runtime.freeMemory(), ThreadGroup.activeCount() и т. д. Я бы не сказал, что префикс get — это прямо "стандарт".
Никто нигде никогда не обещал, что в цепочках if-else будет анализ на exhaustiveness. Он планируется в switch, когда там прикрутят паттерны. Но пока этого нет.
А лучше по новым. Например, изучать только новый синтаксис switch, который удобнее и логичнее. А старый с двоеточием не изучать вообще или оставить как дополнительный материал.
И пока что мне ещё никто не ответил, как в Kotlin решаются проблемы с Entity или как сделать билдер, или как преобразовать неизменяемый объект в билдер, а потом из билдера получить новый объект. Или ещё 100500 юскейсов которые отрабатывает Lombok.
В Котлине билдеры не нужны вообще. Для этого есть copy.
Ну теоретически можно сделать контекстно-зависимое ключевое слово open, которое является ключевым только в списке модификаторов. Собственно, слово sealed так и добавлено: вы спокойно можете иметь метод sealed или переменную sealed.
Чего ж ты не написал свои гениальные идеи в мейлинг-лист? :-) Кстати, ещё не поздно: фича не финализирована, ключевое слово вполне можно поменять. Иди в amber-spec-comments и предлагай! На Хабре-то тебя Брайан не прочитает :-)
Всё просто. Shape — это интерфейс. Рекорды могут реализовывать интерфейсы. Есть у него точка в виде поля или нету — никого волновать не должно. Квадрат может быть удобно задать центром и длиной стороны, а может быть углом и длиной стороны. В одном из случаев метод, который возвращает центральную точку, не будет тривиальным геттером, а будет вычислять значение. Должна быть возможность тривиальным образом сменить одну реализацию на другую, не сломав ни одного клиента. Абстракция! Рекорд по определению имеет прозрачную структуру, он не обеспечивает абстракции.
Тут, например, можно почитать на эту тему.
Это и называется flow typing. И в Java он не реализован и не будет. Об этом я и говорю. Вместо этого в джаве вводится новая переменная — такого синтаксиса в Котлине нет.
Согласен, написано немного запутано.
Байткоду-то какая разница? В байткоде это тоже может быть две области. Байткод тут ни при чём.
К сожалению, старая школа ООП вбила этот ужасный паттерн наследования реализаций. Наследование — это специализация. Совершенно очевидно, что точка в трёхмерном пространстве не является специальным случаем точки в двумерном пространстве. В таком наследовании нет смысла.
Возможность наследования убила бы инварианты рекордов. Например, совершенно непонятно как правильно автоматически сгенерировать equals для рекорда, если его можно наследовать. Ломбок не заморачивается семантикой и дизайном языка, он просто пихает фичи. Ломбок как раз является синтаксическим сахаром в отличие от рекордов, которые несут семантическую нагрузку.
Это не стандарт, а соглашение. Стандарт говорит "Accessor methods can have arbitrary names" (JavaBeans 1.01a, 7.1). В разделе 8.3 действительно описывается именование на get/is, но в разделе 8.2 ещё раз подчёркивается "However, within Java Beans the use of method and type names that match design patterns is entirely optional".
Фреймворки и утилиты не так уж сильно уже завязаны на него и могут адаптироваться. К примеру, Jackson давно адаптировался.
Тогда вам совсем вынесет мозг такой пример:
Здесь область видимости переменной паттерна состоит из двух несвязанных кусков, разделённых телом if'а.
На мой взгляд, это слишком легкомысленное замечание. Во-первых, речь не только о сахаре. Например, рекорды — это модельная сущность, nominal tuple, тип-произведение, если хотите. Это штука с сильной семантикой, а не просто синтаксический шорткат. Во-вторых, "взяли из Котлина" — это просто неверно. Синтаксически эти штуки непохожи на Котлин, а, например, instanceof patterns вообще в Котлине прямого аналога не имеют. У Котлина иной путь — flow typing, который в Java никто тащить не собирается. Sealed types — это больше не фича языка Java, а фича виртуальной машины: проверка иерархии делается на уровне VM, и там надо было аккуратно поработать с раздельной компиляцией и т. д. И теперь как раз котлиновские sealed-типы адаптируют, чтобы они были sealed-типами на уровне JVM. И, кстати, sealed-интерфейсов в Котлине не было, и теперь их затаскивают в Котлин из Java. Тоже берут сахар? Даже текстовые блоки синтаксически похожи совсем не на Котлин (где они плохо сделаны), а на Swift. За каждой из этих фич годы исследований и дизайна, а не просто "давайте сделаем как в языке X".
Хм. String.length(), Collection.size(), Process.pid(), Process.exitValue(), Runtime.availableProcessors(), Runtime.freeMemory(), ThreadGroup.activeCount() и т. д. Я бы не сказал, что префикс get — это прямо "стандарт".
А зачем здесь preview? В Java 16 это стандартная фича.
Никто нигде никогда не обещал, что в цепочках if-else будет анализ на exhaustiveness. Он планируется в switch, когда там прикрутят паттерны. Но пока этого нет.
А лучше по новым. Например, изучать только новый синтаксис switch, который удобнее и логичнее. А старый с двоеточием не изучать вообще или оставить как дополнительный материал.
Хм. Удивительно. А мне довольно часто приходится писать и читать такие циклы. Видимо, задачи сильно разные.
Это всё долгий и отдельный разговор, но
В Котлине билдеры не нужны вообще. Для этого есть copy.
Разработчики языка не равны пользователям языка. Ну и насчёт большинства ещё неизвестно.
У forEach другие проблемы.
Это последний пункт.
Такого не будет, не переживайте.