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

Question

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

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

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

Есть ли какой-либо проект использования аннотации проекта scala?

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

Answer 1

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

немногих мест, которые я видел аннотаций использовал:..

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

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