Почему scala.xml.Atom типизирован?

Question

Я заметил, что scala.xml.Atom принимает параметр типа A, хотя все его подклассы расширяются Atom[String], и в документации сказано: "Класс Atom предоставляет узел XML для текста (PCDATA)."

Существуют ли допустимые сценарии использования для создания экземпляра Atom с параметром типа, отличным от строки?

Более конкретно, я заинтересован в использовании литерала Scala XML для определения своего рода симпатичного DSL для определенияструктура документа на основе дерева памяти, где многие из узлов будут существующими классами scala.Было бы очень хорошо использовать <document>{new JButton("Hi")}</document> и обращаться к нетекстовым данным в Atom[JButton] без необходимости определения схемы сериализации XML для каждого существующего класса.

Это законный вариант использования илиЯ злоупотребляю текущей реализацией библиотеки XML Scala?

Answer 1

Если вы посмотрите на http://sites.google.com/site/burakemir/scalaxbook.docbk.html?attredirects=0,, вы обнаружите, что Atom действительно был предназначен "для узлов, содержащих данные любого типа, например, int, Date".

Как вы заметили, встроенные выражения внутри элементов превращаются в атомы, если они не являются строками, например

<foo>{42}</foo>

имеет в детстве атом [Int].

Чтобы добавить атом в значение атрибута, вы должны написать

<foo life={new Atom(42)}>

(В «книге» это был просто Atom (42), но это было тогда - Atom больше не является классом прецедентов, поскольку наследование класса прецедентов устарело.)

Итак, да, то, что вы хотите сделать, полностью соответствует духу замысла.

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

Answer 2

если вы посмотрите на источники , причина раскрывается. Atom является универсальным, потому что он преобразует переданный объект в строку. Таким образом, вы можете передать ему JButton, но тогда он просто вызовет свой метод toString. (строка 48 имеет значение)

Полагаю, можно вернуть данные из атома:

val doc = <document>{ 42 }</document>

doc.child.head match { 
  case i: Atom[Int] => i.data / 7 
  case _ => error("Unsupported type")
}

возвращает 6. Так что твой план сработает. Я все еще думаю, что дерево, основанное на абстрактных классах и классах case, было бы лучшим выбором, потому что с вашим методом исчезла вся безопасность типов, так как вы можете передавать все, так что ошибки типов не будут обнаружены до времени выполнения.