Комментарии 26
קשה מדי
А где опенсорс либа?)
О! Еще одно подтверждение - любой достаточно продвинутый язык конфигурации стремится стать эквивалентом машине тьюринга, и превратиться в язык программирования без адекватных инструментальных средств, проверки синтаксиса, отладчика, но с комьюнити из целых нескольких человек... :-)
; object3_unite 'object1 + 'object2
object3_unite {
id 2
name "Object One"
color red
поручик, а почему не объединились числа, строки и идентификаторы?
раскладец, батенька, раскладец! (С)
К чему хотелось бы придраться =)
Убрал двоеточие и запятые - если опционально то ок. Иначе зря.
Про запятые говорю те, которые пишутся в столбик (как в sass необязательные ";" в конце свойств). Допустимая запятая после последнего ключа - ок.
кстати, если убрать еще и фигурные скобки, то получится почти yaml =)
Ну и главное - для удобного использования нужны плагины для популярных IDE, f их нет, насколько я понимаю, раз уж сам парсер даже в открытом доступе не присутствует.
ну а так в целом - интересно. на плюсик тянет =)
Да, двоеточия и запятые можно опускать по желанию, любой JSON - это валидный Av. Можно даже смешивать и где-то писать их, а где-то - нет. Мне просто не нравится, как выглядит смешанный вариант, вот и не привёл такой пример.
Если говорить об альтернативных форматах json, то лично для меня основной стоп-фактор их использования - отсутствие поддержки в IDE. Иногда хотелось бы использовать в качестве конфига и при этом не заморачиваться с лишними кавычками (в ключах) и добавлять комментарии. Пакетов полно. Но открываешь такой файл в редакторе и он весь красный. Думаешь - да в *опу, заюзаю конфиг в виде php массива.
HOCON уже видели? :)
Да, видел. Может быть, я ошибаюсь и это на самом деле круто, но мне не очень нравится идея настолько неявной конкатенации строк, массивов и объектов. Плюс там пробелы и переносы строк гораздо важнее, чем в JSON или Av, что мне тоже не очень нравится. Пример ниже (из документации HOCON) как раз демонстрирует то, что мне не приглянулось.
// this is an array with one element, the string "1 2 3 4"
[ 1 2 3 4 ]
// this is an array of four integers
[ 1
2
3
4 ]
// an array of one element, the array [ 1, 2, 3, 4 ]
[ [ 1, 2 ] [ 3, 4 ] ]
// an array of two arrays
[ [ 1, 2 ]
[ 3, 4 ] ]Любой JSON - валидный HOCON, так что пробелы и переносы строк там важны только в случаях, когда используется только сокращенный синтаксис без кавычек. Но в HOCON ещё и другие интересные фишки: включения документов, reference.conf, ccылки на иные параметры. Ваша попытка создать шестнадцатый стандарт интересна, конечно, но пока укладывается в картинку https://imgs.xkcd.com/comics/standards.png
Но серьезно, достойно уважения. Я бы присмотрелся скорее к YAML и сделал что-то похожее на него в духе переделки JSON в HOCON. В конце концов для конфигов более всего важна человекочитабельность.
Пару лет назад писал программу, использовавшую очень большие и развесистые конфигурационные файлы - сперва эти файлы были в JSON, но возможности закомментировать часть файла очень не хватало, переделал на YAML, тем более его как-то в целом удобнее было руками редактировать. Через какое-то время стало не хватать возможности, не повторяясь, описывать структуру вложенных директорий, вместо того, чтобы к каждому файлу данных прописывать полный путь (YAML позволяет расширять парсер, дописал сам), как-то типа так:
- myfolder/
-- somefile.abc
-- anotherfolder/
-- -- anotherfile.xyzНе помню уже синтаксис ни своей писанины, ни даже самого формата YAML, но идея, думаю, понятна. Ваш формат не умеет что-то такое "из коробки"?
в JSON, но возможности закомментировать часть файла очень не хватало
Если вопрос только в этом, почему бы не сделать простейший препроцессор в пару строк bash или Perl, чтобы отфильтровывал закомментированные условным символом строки?
Понятно, что комментировать нужно будет с умом, чтобы сохранить валидный JSON без отфильтрованных строк, но для внутреннего употребления это не проблема?
Если бы уже достаточно много этих конфигов было написано в JSON, то, возможно, так бы и сделал. А так - погуглил, чо там как с поддержкой комментариев, в YAML поддерживаются, да и синтаксис показался погуманнее, чем в JSON. Опять же, синтаксис в редакторах корректно подсвечивается, code folding корректно работает, и вот это вот всё. А "комментировать с умом" - это ж везде надо, хоть в JSON, хоть в YAML, хоть в C++.
Если вопрос только в этом, почему бы не сделать простейший препроцессор в пару строк bash или Perl, чтобы отфильтровывал закомментированные условным символом строки?
Потому что будет негде взять редактор, который поймёт как это поделие форматировать и подсвечивать синтаксис.
Если честно, о таком не задумывался, вот моё решение. Допустим, что в ОС, где мы используем Av, знак вопроса не может встретиться в имени директории. Тогда можно создать мапу, в которой он будет ключом для массива файлов, а имена директорий будут ключами к объектам, которые они описывают.
Допустим, структура проекта такая (не нейронка, у самого похожий есть):
example_project
├── config
│ └── environments
│ ├── development
│ │ ├── database.txt
│ │ └── settings.txt
│ └── production
│ ├── database.txt
│ └── settings.txt
├── app
│ ├── core
│ │ ├── controllers
│ │ │ └── museum
│ │ │ ├── create.txt
│ │ │ ├── read.txt
│ │ │ ├── update.txt
│ │ │ └── delete.txt
│ │ ├── models
│ │ │ └─── museum
│ │ │ ├── schema.txt
│ │ │ └── validations.txt
│ │ └── services
│ │ └── museum
│ │ ├── create_service.txt
│ │ ├── read_service.txt
│ │ ├── update_service.txt
│ │ └── delete_service.txt
│ └── utils
│ └── logging
│ ├── file_logger.txt
│ └── console_logger.txt
├── assets
│ ├── images
│ │ └── logos
│ │ ├── main_logo.png
│ │ └── footer_logo.png
│ └── styles
│ └── themes
│ ├── light.css
│ └── dark.css
├── tests
│ ├── integration
│ │ └── controllers
│ │ └── museum_integration_test.txt
│ └── unit
│ ├── models
│ │ └── museum_unit_test.txt
│ └── services
│ └── museum_service_test.txt
├── main.txt
└── .gitignoreТогда я описал бы её следующим образом:
; map on value place means that there's inner directory at right
narrow_project {
; any name allowed in Av, but forbidden as path part
; could be used there
? ["main.txt" ".gitignore"]
config/environments {
; array on value place means that there's file list at right
development ["database.txt" "settings.txt"]
production ["database.txt" "settings.txt"]
}
app {
core {
controllers/museum [
"create.txt"
"read.txt"
"update.txt"
"delete.txt"
]
models/museum ["schema.txt" "validations.txt"]
services/museum [
"create_service.txt"
"read_service.txt"
"update_service.txt"
"delete_service.txt"
]
}
utils/logging ["file_logger.txt" "console_logger.txt"]
}
assets {
images/logos ["main_logo.png" "footer_logo.png"]
styles/themes ["light.css" "dark.css"]
}
tests {
integration/controllers ["museum_integration_test.txt"]
unit {
models ["museum_unit_test.txt"]
services ["museum_service_test.txt"]
}
}
}То есть:
В директории есть другие директории - использую мапу, где по некоторому ключу - у меня это знак вопроса - лежит массив файлов
В ней есть только файлы - использую массив с файлами.
В смысле, это идея, как можно сделать, или вы в своей мудрости настолько предусмотрели, что уже так работает?
Я нашёл пример своего ямловского конфига, вот так это выглядело:
# the most basic path prefixes
inp: &inp ../data/input/
out: &out ../data/output/
my_files: !paths
- *inp
- - auxiliary_data/
- - some_file.yaml
- another_file.yaml
output_dir_prefix: !path &output_dir_prefix
- *out
- - result_dir/
final_output_dir1: !path
- *output_dir_prefix
- - subdir1/
final_output_dir2: !path
- *output_dir_prefix
- - subdir2/
- - subdir3/После парсинга переменные my_files, final_output_dir1 и final_output_dir2 содержали в себе полные пути:
['../data/input/auxiliary_data/some_file.yaml', '../data/input/auxiliary_data/another_file.yaml']
../data/output/result_dir/subdir1/
../data/output/result_dir/subdir2/subdir3/Мне иногда прям бывает даже странно, что до сих пор ни в каких форматах ничего подобного не предусмотрено - вроде ж, не сказать чтоб редкий случай. Но вот нет - пишите полные пути, в лучшем случае определите алиасы и каждый раз копипастите их в начало пути.
Выскажу непопулярное мнение - стандарт он для того и стандарт , чтоб брать и использовать . Один раз ознакомился , и дальше понимаешь как это работает .
История : коллега занимается внедрением по. По всей стране развернуты сотни кластеров. Сервера общаются между собой. Все хорошо пока не происходит сбой. Причем масштабный. Он дампит обмен серверов . А там json не валидный . 2 дня он не мог понять что это за херня , то ли оборудование глючит , то ли пакеты не доходят , то ли хер знает что... Потом выяснилось что этот json не ,json вовсе, а какое то выблеванное подобие.
Какой то мудак, изобрел свой протокол обмена.и уволился. Было это лет 10 назад и до сбоя никто про это не знал.
Вся история к тому что , не едите мозги ни себе ни людям .
Конфигурация - yaml ,.env, и куча другой херни
Обмен данными - json, xml и то же готовых форматов ДОХЕРА!
Не нужно пихать хер в точилку!!!!
Очередной смузихлеб запихает это в проект, не дай бог уйдет в прод. А потом этот понос всей команде выгребать. С дикой болью и седым менеджером проекта. Который пытается обяснить директору какого хера парк серверов лежит, когда контора теряет сотни тысяч каждый час.
Так проблема была в том, что был изобретён свой протокол обмена? Или в том, что его изобретатель был мудак? Или в том, что изобретение было нигде не задокументировано и поэтому стало проблемой, когда он уволился? Протокол-то что был - "лучше", "хуже", "такой же, но другой", может, фичи какие-то имел дополнительные, которые нужны были?
Так-то мнение не то что популярное, а общепринятое - не надо изобретать велосипед. Существует готовое решение, устраивает? Бери, пользуйся. А если не устраивает? Можно было бы до сих пор сидеть у пещеры и красный цветок кормить, а то и не кормить, если не одобрят старшие обезьяны, скажут, был тут мудак, развёл костёр и пошёл леопардом съелся.
Хотя, конечно, постановки проблемы в посте автора как-то не хватает - с чего вдруг захотелось изобрести новый JSON, чего в старом так сильно не хватало?
Согласен, есть же формат .ini, идеален для конфигов, читабелен, больше 30 лет формату. Все эти хипстерские json, yml и прочее даже рядом не стоят, но нет же, пихают в проекты, надо показать что все типа по современному.
Лично мне хватило просто перейти на JSON5 (https://json5.org/). Полностью совместим с JSON, плюс: есть комментарии, запятая после последнего элемента массива не является ошибкой, если имя ключа map слово без пробелов, то кавычки можно не ставить, также есть шестнадцатеричные константы и многострочные сроки.
Хотя тут есть возможность иметь переменные и вычислять что-то на лету. Мне это нравится, но пока не было в этом необходимости.
Я для таких целей просто беру Lua c отрезанной частью стандартных библиотек. Одновременно и нормальный ЯП со всеми средствами разработки, и вполне приемлемый синтаксис для конфигурации.
Как я писал простой язык конфигурации и в итоге перемудрил