для дополнительных проверок компилятором/статическими анализаторами кода (@Override, @Deprecated, @FunctionalInterface и иже с ними).
Для описания мапингов и прочих архитектурных связок их использовать плохо, так как это не прозрачно и не типо безопасно (большинство таких аннотаций обрабатывается в рантайм рефлексией, которая непрозрачна и не типобезопасна).
Тем более это верно для Kotlin, где архитектура приложения может описываться на том же языке, что и алгоритмы, благодаря наличию дженериков, функций высших порядков и прочих высокоуровневых абстракций.
Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком?
Дичайше плюсую (и разрабатываю очередной способ выражать это всё языком).
+1. Молитесь, чтобы в обработке хиберовского @OneToMany никогда не закрадывалось багов. Закрадётся - взвоешь разбираться, почему оно упало
Это верно, проблема только в том, что сейчас не такой уж большой выбор фреймворков типа экспозед
Но хочется придумать таки (нормальный!) способ к полям добавлять метаданные.
>Зачем вообще использовать мета язык (аннотации) для описания того, что может быть описано языком? Думаю, вопрос в определённом сорте удобства: людям нравится иметь это под рукой прямо в том же месте, где сами сущности, к которым это относится, объявляются - условно, видеть @Transactional в спринге в тех компонентах, где применяется соответствующая аннотации логика, а не в AbstractPersistenceTransactionConfigFactoryBean (утрирую!) где-то очень далеко. Трейд-офф типобезопасности/компайл-тайм корректности приложения с простотой поддержания контекста при разработке и собственно разработки.
не соглашусь
Обсуждают сегодня