и конфиги как раз их и хранят

или так. по хорошему нужно доразобраться с gtk property в D

прошу прощения, не увидел и пропустил вопрос, в мессенджере его легко потерять. Я к формату не хочу привязываться). Помню у меня в каком-то приложении были проблемы с точкой в имени ключа, вроде что-то с ini файлами было, то ли когда конфиг на этот формат переводил, то ли с него, там точка трактовалась как спецсимвол в ключе и в ini файле вроде как секция искалась, как секция.ключ или что-то такое.

для каждых форматов свои правила, они непредсказуемы в целом.

тогда он попадет в сквозную логику, это завязка всего приложения на него по сути

я бы так не морочился, но сколько я себя помню, у меня всегда были проблемы со сквозной логикой и с либами в ней

у тебя и так же приложение на gtk завязано?

ну в любом случае, тогда можешь написать свой GValue

верно, но конфиг находится в модуле, где нет gtk, я его копирую в\из другого cli-приложения, которое ничего о gtk не знает. Таким образом, я вношу изменения в несколько пет-проектов и в этом конфиг и в том, где нет gtk.

У меня есть ощущение, что ты пытаешься сделать боинг, когда твои проблемы решит велосипед. Но это так, детали.
Откидывая вопрос "зачем делить конфиги?", остается парочка вопросов.
1. Почему ты говоришь что хочешь абстрагироваться от конфига, но при этом не видишь смысла в абстрагирующем слое-маппере смысла?
2. Почему нельзя сделать конфиг синглтоном и не париться с прокидыванием на все уровни логики? Тут же не react в конце концов?

Сам я лишней работы как раз таки не хочу, у меня и так мало времени. но, например, на D у меня уже 6 петов, мне нужно как-то поддерживать их и между ними шарить изменения, причем желательно максимально сближаться с проектами на других языках. Если я буду каждый раз в каждом все переделывать, то я угрохаю кучу времени. Проще бы выделить либы и просто подключать их к проекту, но я сразу же откинул этот вариант, это не позволяет делать быстро хренак-хренак и в продакшн, нужно каждый раз править их, нарушая работу других проектов и проще каждый проект делать монолитным, а копировать сурсники, но они должны быть расслоены для этого. Отсюда все сложности, мало времени + много разных проектов, каждый из которых чем-то для меня полезен, ну и как-тут по другому делать.

>  но при этом не видишь смысла в абстрагирующем слое-маппере
про маппер не понял, у них уровни разные. Мой конфиг более низкоуровневый и построен на ключ-значение, маппер из ключ-значения рожает объект, но как и в реальности эти роды могут закончиться по-разному в разных ситуациях). Как я выше написал, у меня мало времени, чтобы эту логику педалить и вылизывать в ней баги.

> прокидыванием на все уровни логики
Реакт не юзал, не знаю, подозреваю, что речь идет о контейнере зависимостей, который сам по себе глобален, а уже сервис конфига или что там получается из него или что-то такое. Если же грубой статикой, то когда компонент пробрасывает другому зависимость, то это типичное дерево, где какой-то узел может заменить конфиг и передать дочерним компонентам что-то другое, например, плагины могут использовать свой конфиг, который хранится в директории с плагином, но грузится обычным модулем конфига и работа идет ровно также, как если бы это был конфиг приложения, просто он им подменяется, а может и не подменяется, в зависимости от хотелок. А если завязать что-то в логике работы плагинов на конфиг приложения, то тут могут быть неприятности скорее всего.

1. Про маппер теперь я вообще запутался. Потому что система (в моем представлении) получается такой:
- Парсер конфига, который рожает прибитые к формату данные. Его НЕ НУЖНО наследовать и расширять в принципе
- Маппер, зависимый от формата
- Итоговый конфиг-объект, с которым все должны работать
Мы говорим о первом уровне или о третьем? Пока мы не разберёмся, смысла в остальном нет. Я, если что, говорил про третий.

парсер и всё прочее лучше отделять. Например, считаем, что на вход пришли настройки. Тут можно думать, как их хранить и как предоставлять пользователю. А всё в кучу сразу мешать - запутаешься

Для самого простого моего случая, если добавлять маппинг, то: при парсинге либа конфига выдает на выходе какую-то структуру данных. Это структура хранится на поле и к ней можно пробовать организовать доступ ключ-значение, при этом тут и работает getValue, setValue, формат конфига тут известен, в каждом случае свой способ сохранения и т.п. Затем маппер получает эту обертку или уже этот ассоциативный массив\аналог и ничего не зная о формате заполняет объект конфига по имени\типу поля, здесь отображение ключ-значение на поле-значение, ему все равно откуда данные. На выходе маппера и получается "итоговый конфиг, с которым все должны работать". Обратный путь такой же - маппер выдирает из полей ключ-значение и передает данные в обертку специфической либы, она ничего не знает об объекте конфига и был ли он вообще. Конечно, сам мапинг можно построить по разному, но если маппер будет и заполнять объект и управлять специфической либой, то встает вопрос, что он делает две работы в одно лицо.

к слову, также можно построить самый простой дата-маппер для бд.

хотя он скорее всего на костылях будет и багованный весь.

А-а, понял

Ты хочешь независимый от формата слой между парсером и маппером, так?

похоже на то). Вообще, я даже не помню почему я выбрал именно такой подход. Вспоминаю, что было одно приложение с большим количеством конфигов и там был агрегатор их, который ничего не знал, что где находится. Он тупо перебирал все конфиги, проверял, есть ли где-то ключ, устанавливал значение и вызывал save. Возможно это ключ-значение оттуда пришло, с другой стороны, конфиги вообще штука сама по себе проблемная, сколько я раз их менял одни на другие...