Почему scala людям не нравится аннотация?

Атрибут в .NET - очень популярная функция. И добавлена Java Annotation после 1.5 Аннотации используются повсюду, см. Java EE и Spring. Но несколько библиотек библиотеки scala используют аннотацию. lift-json не использует его. лифт-запись не использует его. Squeryl не использует его. subcut не использует его (он имеет аннотацию для плагина компилятора) ... Просто назвали несколько.

Они используют аннотацию только тогда, когда им нужна магия компилятора. @tailrec, @inline, @BeanProperty, @Inject (в подстроке)...

Scala имеет супер гибкую систему типов, черту, неявный и Menifest [X]. Таким образом, им не нужны метаданные времени выполнения?

Существует ли какая-либо аннотация для проекта scala?

p.s. Я думаю, что Dynamic должен быть аннотацией, но не признаком.

Ответ 1

В общем, мы не используем аннотации, потому что нам они действительно не нужны для многих вещей.

В нескольких местах, которые я видел, используются аннотации:

Системы дополнительного типа (например, CPS-плагин для разграниченных продолжений или плагина отслеживания эффектов.
Взаимодействие с устаревшими интерфейсами Java. (scala-mojo-support)
Выполнение/включение оптимизаций компилятора, например @inline или @tailrec.

В Scala нам действительно не нужна инфраструктура инъекции зависимостей, так как есть несколько способов сделать инъекцию зависимостей, которая не требует внешнего инструмента. Вы можете иметь конфигурацию DI отдельно от кода ядра, но все равно записываться в Scala. См.: https://github.com/jsuereth/scala-in-depth-source/blob/master/chapter11/src/main/scala/scalax/config/Test.scala

Итак, основной ответ: нет ничего плохого в аннотациях, мы просто не нуждаемся в них так часто (пока).

Ответ 2

Для меня часто возникает проблема безопасности принудительного типа компилятора. Взгляните на Squeryl и как он отличается от Java ORM, как Hibernate. Если Hibernate будет использовать аннотацию @Id для обозначения первичного ключа, в Squeryl вы создадите элемент id, который задается признаком KeyedEntity. Методы, требующие сущности с первичным ключом (например, обновления и удаления), будут громко рушиться во время компиляции, если они не определены. В Squeryl есть несколько других мест, где конструкторы типов заменяют аннотации, такие как сопоставление коллекции и обработка даты и времени.

Я думаю, что это общий способ мышления в сообществе Scala. Аннотации являются скорее функцией времени выполнения и не так хорошо расценены. Компилятор Scala очень мощный и выдвигает больше вашего кода в конструкции, которые он может проверить, имеет смысл для тех, кто готов принять сложность, которая приходит вместе с этим.

Ответ 3

Вы очень хорошо ответили на свой вопрос, когда сказали, что они используются для магии компилятора. Для других применений это обычно какая-то магия времени выполнения, где два основных инструмента - отражение и преобразование байтового кода.

Для случая JSON выбор для преобразования будет следующим: 1. Функция или класс, который анализирует ваш JValue и строит ваш класс T. 2. Отражение над целевыми классами для определения их компоновки и того, что является факультативным, а затем некоторый "динамический" код, который обрабатывает эти анализируемые данные для создания, а затем в конечном итоге приводит к соответствующему типу.

Ответ 4

Все аннотации, такие как @tailrec и @inline, являются только компиляцией. Они расширяют StaticAnnotation, а именно AFAIK, единственную поддержку аннотаций в Scala, и они не будут сохранены во время выполнения. Я думаю, что философия состоит в том, чтобы избежать аннотаций во время выполнения, потому что они извлекаются через отражение, мир, где компилятор больше не может помочь вам за пределами стандартных классов из-за стирания типа, но самое главное, потому что это время исполнения и цель состоит в том, чтобы решить, re пытается решить во время компиляции.

Посмотрите на использование аннотаций для моделирования вывода JSON, например: В Java вы бы знали, работает ли он нормально при запуске вашей программы. В Scala вы можете использовать классы типов для моделирования того, как каждый тип выражается в JSON. Если вы пропустите одно определение, компилятор скажет вам. Прекрасным примером является spray-json.

Дэйв Уиттакер дает еще один отличный пример в своем ответе .