Комментарии в формате JSON
Наткнулся случайно на ссылку, где автора очень изящно решает проблему комментариев в формате «джейсон». Это лучшее решение, которое я только видел (обычно либо выделяют специальный ключ, либо расширяют формат). Только поглядите:
{
"api_host" : "The hostname of your API server. You may also specify the port.",
"api_host" : "hodorhodor.com",
"retry_interval" : "The interval in seconds between retrying failed API calls",
"retry_interval" : 10,
"auth_token" : "The authentication token. It is available in your developer dashboard under 'Settings'",
"auth_token" : "5ad0eb93697215bc0d48a7b69aa6fb8b",
"favorite_numbers": "An array containing my all-time favorite numbers",
"favorite_numbers": [19, 13, 53]
}Он полностью синтаксически верен и разбирается правильным образом во всех языках, по всей видимости.
Комментарии 38
Мда? Ну вот, скажем, Perl был разработан не для веба, а Си весь вызывает ощущение кривизны.
surrounding zero or more name/value pairs (or members). A name is a
string. A single colon comes after each name, separating the name
from the value. A single comma separates a value from a following
name. The names within an object SHOULD be unique.
RFC 2119
Неправильно работает парсер Yaml в Symfony, но он и в целом плохо парсит JSON
(т.к. json подмножество yaml, неплохо бы не терять эту совместимость)
Ошибаюсь, 2.0 не существует, как раз с 1.2 перепутал.
Ну так и утверждение «там всё такое» тоже неверно.
ага, но там даже не Yaml 1.2, а «selected subset of features» из Yaml 1.2
Закладываться на такое поведение не рекомендуется — можно в один прекрасный момент наткнуться на интересные баги. Если нужны комментарии в JSON, возможно стоит обратить внимане на другие форматы. Или остановиться на том же YAML (для которого, кстати, JSON не является полным подмножеством — там есть пограничные случаи когда JSON не будет соответствовать стандарту YAML).
Да и проблем, описанных вами, я не вижу. Очевидно же (или нет?), что формат с комментариями нужен не для обмена (зачем там комментарии?), а я для хранения (конфигов и
Комментарий для Евгения Степанищева:
В таком случае возникает вполне логичный вопрос: «а зачем нам JSON?». Или перефразируя: «а зачем нам втыкать костыли в формат, не предназначенный для конфигов?». Есть много других замечательным форматов для конфигурации как то YAML, INI, TOML…XML в конце концов. Тем более, что парсить его будет управляемый нами код. Понимаю, что адаптировать любимый инструмент под случай, на который он не рассчитывался, всегда интересно, но это редко когда заканчиваетсячем-то хорошим.
И никто не гарантирует, что в
Комментарий для kxepal:
Не люблю зоопарки, в том числе и форматов. JSON хорош как для конфигурирования, так и для обмена данными. INI для обмена данными плох, YAML сложный, XML ужасен, что такое TOML я не знаю и, видимо, знать этого мне не нужно.
Да что тут адаптировать? Оно ж само работает. Причём понятно каждому, кто хоть раз писал парсер, почему оно так работает.
я и не предлагал обмениться данными в этом формате. Ини -- настройки, джейсон -- транспорт.
В этом случае не придется изобретать костыли.
Мда? Как же хранить в
# some.ini
[mysection]
myarray = 1 2 3 4 5
# some.code
myIni.read('/path/to/file')
myIni.getIntArray('mysection', 'myarray')
То есть никак? Вот у меня есть такой массив в джейсоне, например:
{"APM": [1,3], «other»: [8], «KKM»: [5,2]}, что с ним делать? А бывают структуры и ещё более сложные.
Что значит никак? Ини файл предполагает упрощение структуры данных.
В вашем случае в
Сложные древовидные структуры очень плохо поддаются редактированию человеком. Добавить новое поле в объект на третьем уровне сложности становится реально тяжело. Про перестановки с места на место вообще не говорю. Настройки нужно упрощать, сложные структуры проводить к линейному виду.
Я вот смотрю на конфиг нашего проекта (он в «джейсоне»), там аж до 7 уровня сложности есть и не ощущаю ровно никаких сложностей в его редактировании. Не вижу никакого смысла приводить нормальные сложные структуры, где ещё и типы сразу видно, к плоским
Конфиг в 7 уровней кажется вам удобным только потому, что вы с ним каждый день работаете.
И вы не можете вписать в него комментарий нормальным способом. Как разбирать этот ад без коментов -- загадка. Если делать это дублирование полей, то такой комментарий не будет выделен цветом и его трудно увидеть. И можно случайно переставить порядок ключей при редактировании и зафакапиться.
Комментарий для Иван:
По документации? На ад, кстати, он совсем не похож. Кроме того, в нашем конфиге комментарии всё же есть — мы расширили JSON.
Комментарий для Евгения Степанищева:
Вок к каким велосипедам можно прийти, если использовать формат не по назначению.
Вы так говорите, как будто велосипеды — это плохо.
Конечно плохо. Вместо того, чтобы упростить структуру конфига, вы выбрали не самый подходящий формат + кастомная работа с ним. Больше кода, больше энтропии, больше времени нужно новичку для адаптации.
Комментарий для Иван:
вообще-то. ini-файлы это уж точно не формат, подходящий для конфига, потому что у него нет типов данных, у него есть интерпретация и она зашита в коде, не читая код, нельзя сказать что перед нами.
Да ничего подобного. Новички читают этот конфиг, даже не замечая, что комментариев там быть не должно
Вы мне предложили сделать буквально следующее:
Это одни из самых зверский костылей, которые я только видел.Во-первых, секция должна быть вложена тут в другую секцию, а та — в свою, это будет очень нечитаемо, во-вторых, неясно что перед нами: массив чисел? Строка? Как перемешать в массив числа, строки, булевы значения и null? Думаю, что вы просто предло́жите какое-то соглашение, которое будет интерпретироваться на уровне кода. JSON туда куда лучше.
Комментарий для Евгения Степанищева:
в джейсоне тоже ограниченная система типов. в реальном проекте вам потребуется хранить даты, регулярки. Например, чтобы получился datetime, нужно нужно распарсить строку, а для регулярки получить скомпилленый объект.
зачем вкладывать? у вас естькакой-то словарь, ему можно присвоить имя и записать в секцию. делайте данные линейными. ваша вложеность на 7 уровней -- дело только ваших рук. Вы в курсе, что питоноский LoggingDict может быть свободно описан в ини-файле?
я коров с лошадьми не мешаю. Это явно неудачный кейс.
Комментарий для Иван:
Ну, у меня проект реальный. Я описываю с тем, с чем сталкиваюсь.
Потому что есть модули, в них — другие модули. Конфиг отражает эту вложенность. Плоский конфиг ничего не отражает.
В реальной жизни null запросто мешается с остальными типами, это очень частый случай (а не «кейс»).
Комментарий для Евгения Степанищева:
заведите доменную систему имен, типа app.module.menu и будет все норм
массив, в котором все до кучи -- числа, строки, нулл -- этокакой-то нонсенс. Смешанные типы могут пригодиться разве что в jsonschema для проверки входных данных (в отдельном файле)
Комментарий для Иван:
Вы упорно сопротивляетесь нормальному формату, сочиняя костыли на ходу.
Так давайте рассмотрим более простой вариант: однородные скаляры перемешанные с null
в питоне это парсится в [0, 1, 2, None, 3, None, 4, 5] двумя строчками (свой метод в ConfigParser)
Я не хочу уже спорить. Мне не нравится идея не знать на уровне конфига что значат
select json_value('{"api_host" : «The hostname of your API server. You may also specify the port.», «api_host» : «hodorhodor.com»}', '$.api_host') from dual
----
The hostname of your API server. You may also specify the port.