Неа, не оно Насколько вижу, там нет фич, которые есть в ATMC (импорты, мерджи) Но синтаксис похож, да - ну это не удивительно, ведь я ориентировался на js-ные объекты
но не забывая вводить магические переменные для описания циклов — что, по мне, отвратительно
Согласен - поэтому такого у меня не будет - это все-таки язык конфигурации, а не язык программирования
> можно ли отрендерить/экспоритировать .atmc конфиг в другие форматы?
Сейчас можно только в JSON - причем это ненастоящая компиляция в json - применен такой хак: компилим в мапу, а из мапы в json с помощью стандартного пакета - в будущем можно сделать нормальную компиляция, но пока и так сойдет - можем себе позволить так как скорость компиляции не имеет значения:)
Больше ни во что нельзя В планах компилировать в самого себя - то есть выдать один конфиг с отрезолвленными значениями - думаю будет удобно дебажить, как это позволяет делать nginx -T
> как сделать ключ с пробелом?
Никак. А надо?
> можно ли сделать циклы?
Если это про циклические зависимости, то нет - детектится и выдается ошибка
> пофейлится ли конфиг с одинаковыми ключами или есть какое-то правило?
Нет, не пофейлится - можно переопределить значения - это не то чтобы фича - просто так работает - возможно стоит запретить, а то потом такую проблему фиг отыщешь
> при рекурсивном мерже, мержатся ли списки или просто перезаписываются?
Массивы перезаписываются - мердж не позволит переопределить значения в нем, так как ключей там нет, как в объектах
Такое реализовать на самом деле не сложно - можно любой формат переложить в мапу, сделать это несколько раз для нескольких файлов и сделать мердж
Так и делают чаще всего
Но что не нравится в таком подходе: - список файлов определяется в приложении - то есть без просмотра кода конфигурацию не прочесть - без просмотра кода не понять, по каким правилам строится конфигурация - кто кого переопределяет и все такое
Ну и моя версия включает в себя некоторые другие фичи, которые таким образом не реализовать или можно реализовать, но с помощью костылей
На моем опыте в бизнесовых приложениях не удается обойтись простецким конфигом, который можно было бы удобно описать в ini
Во всех проектах всегда были фреймворки, которые из коробки давали модульность + слияние конфигов - и это прям надо реально. И даже для go приложений такое надо, потому как на нем мы тоже бизнесовый код пишем - сейчас мы мерджим yml
Понимаю проблему сложных конфигов, поэтому пытался найти баланс - добавил ключевые фичи, без которых нереально жить в бизнесовых приложениях ИМХО Постарался в общем не усложнять синтаксис и читабельность конфига
Неа, не оно
Насколько вижу, там нет фич, которые есть в ATMC (импорты, мерджи)
Но синтаксис похож, да - ну это не удивительно, ведь я ориентировался на js-ные объекты
Потому что это сделает конфигурацию абсолютно нечитабельной
Согласен - поэтому такого у меня не будет - это все-таки язык конфигурации, а не язык программирования
> можно ли отрендерить/экспоритировать .atmc конфиг в другие форматы?
Сейчас можно только в JSON - причем это ненастоящая компиляция в json - применен такой хак: компилим в мапу, а из мапы в json с помощью стандартного пакета - в будущем можно сделать нормальную компиляция, но пока и так сойдет - можем себе позволить так как скорость компиляции не имеет значения:)
Больше ни во что нельзя
В планах компилировать в самого себя - то есть выдать один конфиг с отрезолвленными значениями - думаю будет удобно дебажить, как это позволяет делать
nginx -T> как сделать ключ с пробелом?
Никак. А надо?
> можно ли сделать циклы?
Если это про циклические зависимости, то нет - детектится и выдается ошибка
> пофейлится ли конфиг с одинаковыми ключами или есть какое-то правило?
Нет, не пофейлится - можно переопределить значения - это не то чтобы фича - просто так работает - возможно стоит запретить, а то потом такую проблему фиг отыщешь
> при рекурсивном мерже, мержатся ли списки или просто перезаписываются?
Массивы перезаписываются - мердж не позволит переопределить значения в нем, так как ключей там нет, как в объектах
Такое реализовать на самом деле не сложно - можно любой формат переложить в мапу, сделать это несколько раз для нескольких файлов и сделать мердж
Так и делают чаще всего
Но что не нравится в таком подходе:
- список файлов определяется в приложении - то есть без просмотра кода конфигурацию не прочесть
- без просмотра кода не понять, по каким правилам строится конфигурация - кто кого переопределяет и все такое
Ну и моя версия включает в себя некоторые другие фичи, которые таким образом не реализовать или можно реализовать, но с помощью костылей
На моем опыте в бизнесовых приложениях не удается обойтись простецким конфигом, который можно было бы удобно описать в ini
Во всех проектах всегда были фреймворки, которые из коробки давали модульность + слияние конфигов - и это прям надо реально. И даже для go приложений такое надо, потому как на нем мы тоже бизнесовый код пишем - сейчас мы мерджим yml
Понимаю проблему сложных конфигов, поэтому пытался найти баланс - добавил ключевые фичи, без которых нереально жить в бизнесовых приложениях ИМХО
Постарался в общем не усложнять синтаксис и читабельность конфига
А что будет, если мы положим ключ в редис и упадем? Что фронту отвечать? Что запрос обработан или что ошибка все-таки?