Comments 11
Нужно ещё больше парсинга. Парсинг должен жрать как можно больше ЦПУ. А ещё всё ч-з стримы, чтобы их тоже парсить. Весь этот популизм с JSON и CBOR и «зелёная» экономия, совсем не суровый энтерприйз. Как можно жить беза стэка из 10 парсеров?
Когда волшебные единороги будут кушать радугу и на выходе будет один лишь эффективный, компактный бинарный формат, то жизнь разработчиков, в окружении бабочек, станет радостной и беззаботной. А пока приходится извлекать и трансформировать то, что выдают десятки разных приложений в их «родных» форматах.
XML в большинстве случаев можно проверить и десереализовать в объект более-менее стандартными инструментами. А для того, что я нередко вижу на YAML нужен каждый раз какой-то индивидуальный подход. Например, в docker-compose имена серверов — не значения (value), а ключи (key).
Можно подумать, в xml нельзя записать что-то в тело, а что-то в аттрибут тэга. Или вот есть ещё интерксный формат plist, основанный на xml.
Можно. Но в чем проблема-то?
Ну вот выше у человека проблема, что имя сервера в docker-compose.yml — ключ, а не значение. Неужели это большая проблема чем то, что я написал про xml?
Да. Известные мне десериализаторы не испытывают никаких проблем с чтением атрибутов элемента.
А вот в случае когда имя является ключом в json — то единственным вариантом становится десериализация в словарь или какой-нибудь JObject. В обоих случаях имя сервера оказывается «оторвано» от остальной информации о сервере.
А вот в случае когда имя является ключом в json — то единственным вариантом становится десериализация в словарь или какой-нибудь JObject. В обоих случаях имя сервера оказывается «оторвано» от остальной информации о сервере.
«Тело» — надо понимать как содержимое? — аналогом в данном случае будет сам тэг, его имя.
В смысле «более менее», jaxb уже сколько лет? и json-b уже подоспело, ух заживём!
UFO just landed and posted this here
Sign up to leave a comment.
Взаимные превращения JSON, YAML, XML