final static vs companion object
Пишу код для игры на Kotlin. До работы в 2016 учился на Java, но так повезло, что там на работе меня обучили и Котлину. Мне понравилось - язык компактный, Java-совместимый, отечественный. То, что на Джаве писалось в 100+ строчек, часто стало укладываться в 30.
В общем, на Java заходил только ради багфиксинга старых проектов. Естественно, когда начал пилить проекты игры на LibGDX, использовал Kotlin. Только несколько стартовых классов, которые этот фреймворк генерит для нового проекта, оставил на Джаве.
Но через N недель выяснилась, что там, где у Java - честная подстановка константы во время компиляции вместо final static, у Kotlin - вызов в рантайме метода класса companion object. Это в целом для обычных проектов не смертельно никак, но в играх, где 60 раз в секунду в цикле update вызывается ряд констант - существенно (хотя тоже не смертельно).
Короче, переписал я константные классы на Java ради final static. Смотрю на салат из Java и Kotlin файлов и думаю
- Дааааа, показывать такое своему старшему программисту не стоит. Да и на Гитхаб выкладывать тоже, пожалуй. Но в геймдеве могут понять.
В общем, на Java заходил только ради багфиксинга старых проектов. Естественно, когда начал пилить проекты игры на LibGDX, использовал Kotlin. Только несколько стартовых классов, которые этот фреймворк генерит для нового проекта, оставил на Джаве.
Но через N недель выяснилась, что там, где у Java - честная подстановка константы во время компиляции вместо final static, у Kotlin - вызов в рантайме метода класса companion object. Это в целом для обычных проектов не смертельно никак, но в играх, где 60 раз в секунду в цикле update вызывается ряд констант - существенно (хотя тоже не смертельно).
Короче, переписал я константные классы на Java ради final static. Смотрю на салат из Java и Kotlin файлов и думаю
- Дааааа, показывать такое своему старшему программисту не стоит. Да и на Гитхаб выкладывать тоже, пожалуй. Но в геймдеве могут понять.