Comments 30
Ведь у разработчиков же нет такой самоцели, чтобы после появления нового диалекта языка сразу весь старый код на нем начал собираться с поддержкой новый фич.
Чтобы старые проекты можно было продолжать собирать со старым диалектом
После такого всем лень будет поддерживать эту опцию и в итоге она сломается и сквозная совместимость будет утеряна. Это если диалект в общем случае.
А вот если речь идёт про только поддержку ключевых слов то наверно можно — ведь там всего лишь надо отключить распознавание токена как ключевого слова.
docs.oracle.com/javase/6/docs/technotes/tools/windows/javac.html
-target version
-source release
А как будет решаться проблема если вы подключаете библиотеку которая написана на старой Java, а сами пишете на новой?
А как будет решаться проблема если вы подключаете библиотеку которая написана на старой Java, а сами пишете на новой?
Точно так же, как все остальные программисты решают проблему использования легаси-компонент в новом коде. Поискать новую версию, поискать аналог, попросить автора исправить, или сделать это самому, если доступны исходники. С этим разработчики сталкиваются в своей практике регулярно, ничего особо страшного нет, кроме каких-то редких единичных случаев, когда поломался интерфейс какой-то старой, но Очень Необходимой Библиотеки, у которой нет ни исходников, ни аналогов, и о необходимости использования которой стало понятно вот сейчас, когда уже написали полпроекта на новом диалекте, а не на этапе его проектирования.
Для сравнения — в Rust для каждой библиотеки указывается своя редакция языка (2015 или 2018). А если вдруг старая библиотека использует в идентификаторах новые ключевые слова, то даже синтаксис-костыль вида r#async выдумали, чтобы можно было к ним обратиться
Ну, такая проблема на самом деле уже есть — имя метода/поля, это просто строка. Можно даже из пробелов, чем пользуются всякие обфускаторы.
Я вообще .net'чик. В "спеке" java я не нашел ничего про пробелы. Возможно на уровне JVM это так, но на уровне source code нет. В CLR, к примеру, используются идентификаторы с угловыми скобками <>, но в source code это не допускается.
Если в будущем какое-нибудь слова, например, «mutable», «stop», станут ключевыми, можно будет продолжить использовать старые библиотеки, экспортирующие методы или переменные с такими именами, обращаясь к ним как
if (someobj.@mutable) someobj.@stop();Подключение библиотек работает на уровне JVM и правила к идентификаторам дает она же. Что же касается языка Java, никто не мешает вызвать код через рефлексию или сгенерировав байткод. Да даже банально можно написать ClassLoader, который автоматически подменит невозможные в Java идентификаторы возможными. Так что никакой проблемы совместимости нет.
А все эти люди, предлагающие вырвиглазные решения, похоже, не понимают, что эти их решения нужны от силы полпроценту проектов и это число неуклонно будет снижаться в будущем, если их решение все же будет реализовано, зато неудобства от такой обратной совместимости будут влиять на 80% проектов и это число не будет уменьшаться со временем. Л — Логика.
В rust так сделали недавно. Посмотрим к чему это приведет.
пометить сеттер/метод-билдер в качестве возвращающего свой получательЗамечательный перевод, не помеченный как перевод :)
Роберт Мартин: Чистый код. Создание, анализ и рефакторинг. Глава 2. Содержательные имена.
Перечитайте на досуге
Новые ключевые слова в Java