Являются ли названия или символы API отражения scala подходящими для использования внутри объектов переноса?

Question

Введение

Я работаю над API, написанным на Scala. Я использую объекты передачи данных (DTO) в качестве параметров, передаваемых функциям API. Пользователь DTO будет проинструктирован пользователем API.

Поскольку API довольно абстрактный/общий, я хочу указать атрибуты объекта, над которым должен работать API. Пример:

case class Person(name: String, birthdate: Date) 

Когда экземпляр Person «Р» передается API, то API должен знать атрибуты «P» она должна работать на: либо просто name или birthdate, или оба из них.

Поэтому мне нужно создать DTO, который содержит экземпляр «P», своего рода объявление атрибутов и, возможно, дополнительную информацию о типе «P».

Строка подход, основанный на

Один из способов будет использовать String с, чтобы указать атрибуты «P» и, возможно, его тип. Это было бы относительно просто, так как String s были довольно легкими и хорошо известны. Поскольку формальные обозначения пакетов, типов и членов как String s, объявления будут структурированы в определенной степени. С другой стороны, дефиниции String должны быть проверены, поскольку пользователь может пройти недействительно String s. Я мог бы представить типы, которые представляют атрибуты с выделенными типами вместо String, которые могут иметь преимущество увеличенной структуры и, возможно, даже те, которые предназначены для того, чтобы существовали только действительные экземпляры.

Reflection API подход

Конечно отражение API пришла мне в голову, и я экспериментировал объявить атрибуты с типами из Reflection API. К сожалению, API-интерфейс scala 2.10.x является немного неинтуитивным. Есть имена, символы, зеркала, типы, typetags, которые могут вызвать путаницу.

В основном я вижу две альтернативы декларации атрибута с String с:

1. атрибут объявления с отражением API: "Имена"
2. атрибут объявления с Reflection API в "Символы" (особенно спектральный терм)

Если я пойду таким образом, насколько я вижу, пользователь API, который создает DTO, будет иметь дело с API-интерфейсом отражения и его Именами/Символами. Также реализация API должна будет использовать API отражения. Таким образом, есть два места с отражающим кодом, и пользователь должен иметь хотя бы немного знаний об API отражения.

Вопросы

Однако я не знаю, как тяжеловес эти подходы:

• ли имена или символы дорого построить?
• Имеет ли API-интерфейс отражения какие-либо кэширование дорогих результатов операции или я должен позаботиться об этом?
• Являются ли имена и символы переносимыми в другую JVM через сеть?
• Являются ли они сериализуемыми?

Главный вопрос: Являются ли символы отражения scala отражением или символами, подходящими для использования внутри объектов переноса?

Кажется, сложно сделать это с помощью API отражения. Любые подсказки приветствуются. И любые намеки на другие альтернативы тоже.

P.S .: Я еще не включил свой собственный код, потому что мой API сложный, а часть отражения находится в довольно экспериментальном состоянии. Майе, я могу доставить что-то полезное позже.

Answer 1

1a) Имена просты в построении и легки, поскольку они всего лишь немного больше, чем строки.

1b) Символы не могут быть сконструированы пользователем, но создаются внутренне, когда разрешаются имена с использованием API, таких как staticClass или member. Первые обращения к таким API обычно включают в себя распаковку подписей типов владельцев символов от аннотаций ScalaSignature, поэтому они могут быть дорогостоящими. Последующие вызовы используют уже загруженные подписи, но все равно оплачивают стоимость поиска по имени в виде хэш-таблицы (1). declaration стоит менее member, потому что declaration не смотрит в базовые классы.

2) Подписи типа (например, списки членов классов, params + return type of methods и т. Д.) Загружаются лениво и поэтому кэшируются. Также сопоставляются сопоставления между артефактами отражения Java и Scala, а также (2). Насколько я знаю, остальные (например, проверки подтипов) обычно не защищены от нескольких незначительных исключений.

3-4) Артефакты отражения зависят от их вселенной и в настоящий момент не могут быть сериализованы (3).