Комментарии 15
Вроде обсуждение идёт про форматы конфигурации. Их пишут руками. Это бинарный формат.
Для человеко-читаемого формата мне очень понравился toml. Но, Я всё-таки, понял, что речь идёт больше про API. И про накладные расходы на лишний синтаксис. В этом отношении msgpack лучше.
И в целом, читаемый. Я вот более-менее бегло могу читать формат миди-файлов, хотя он тоже вполне так себе бинарный, да ещё и последовательный.
P.S. но вообще JSON хорош тем, что он простой как палка, и даже если ты никогда не видел JSON - ты всё равно его понимаешь.
Для того, чтобы читать а тем более, писать XML, cml, yaml, toml - надо хоть немного разобраться. А лучше иметь под рукой шпаргалку
Текстовый формат, как JSON или UCL, но:
гораздо меньше синтаксического мусора
не мапы ключ-значение, а объекты с типами, именами и полями
не только деревья, но произвольные стркутуры данных с перекрестными сылками между объектами
можно включать бинарные данные
импорты/экспорты позволяют объединять контент нескольких файлов в один DOM
поддержка C/C++ (DOM/StAX) / Java (DOM/StAX/Сериализация) / JS (Сериализация).
Что предлагает UCL
Прочитал тут. Поискал, почитал в Инете. Но так и не понял, как различать "булевы переменные — true, yes, on и соответствующие им false, no, off" и аналогичные по написанию, но строковые по типу данных значения. То же самое и относительно шестнадцатеричных целых и соответствующего строкового значения. А ведь тип значения может быть важным, и даже определяющим...
В теории он должен исправить некоторые проблемы «классического» формата обмена данными.
Если на предыдущий вопрос не найдётся вменяемого ответа, то, как по мне, исправление в общем не сильно критичных проблем ТАКОЙ ценой - не оправдано.
Предполагаю, что как-то так:
booleanVariable = true; stringVariable = "true";
It is still possible to treat numbers and booleans as strings by enclosing them in double quotes.
https://github.com/vstakhov/libucl#convenient-numbers-and-booleans
Но не знаю как это сделали.
Можно - не значит обязательно. То есть потенция неоднозначности имеется, и в рамках допустимого синтаксиса она неразрешима. Что ставит всю разработку под сомнение. Поступил тебе сторонний документ, в нём имеется no - и попробуй угадай, это такое значение или это маркер его отсутствия...
А NULL и/или его аналоги-алиасы я там вообще не нашёл.
Давно уже есть нормальная альтернатива, вы чего?
15_конкурирующих_стандартов.jpg
статья довольно невнятная, если не вредная. какое предназначение у этого синтаксического сахара? удобство/читаемость? тогда почему в этом контексте упомянут обмен данными между серверами, где это вредно (вот тут можно рассказать про msgpack).
Где-то была уже статья про JSON/YAML/... Там предлагали использовать JSON5 - я почитал, и мне в целом понравилось. Почему-то тут его не упомянули.
Мне больше нравится JSON Lines для потоковой обработки.
https://jsonlines.org/
Конфигурация должна быть кодом на Typescript, который json. И все становится хорошо. Вместо ts, можно использовать любой другой статически типизируемый язык. Ныть про то, что нужно таскать с собой node-runtime не нужно, пару сотен мегабайт, это не много. Зато написание конфигурации превращается в кайф.
Ищем альтернативу и упрощаем работу с JSON