Сразу простите за портянку а я всё продолжаю строить архитектуру хранения

настроек приложения

ключевые запросы
) автокомплит в IDE
) защита от появления новых настроек в ядре и сопутствующие проблемы при обновлении ядра и забывчивости внесения новых значений в приложении

идея сделать абстрактные классы со свойствами хранящими дефолтны значения в ядре
а в приложении создание класса екстендящего абстрактный с возможностью переопределения свойств

в принципе показала себя норм, но обнаружилось пару минусов
- даже если не хочешь переопределять класс все равно создать надо (проблема появления новых настроек не решена)
- в свойствах без конструктора невозможно использовать вычисляемые значения, даже self::$other_var ругается

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

+ автокомплит работает
+ отсутствует проблема появления новых конфигов
- нельзя перейти к определению свойства... попадаем в класс с дефолтами и нет возможности попасть на переопределенное свойство (с этим придется жить)

Простите за портянку, кто хочет подискутировать в привате? нужна помощь, вдруг есть какой другой вариант

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

а я тут пока пришел вот к такому https://pastebin.com/RpugQN1x

А как же автокомплит и переход?

автокомплит будет $config = new Config(); $config->... тут будет IDE подсказывать var

Но не новый же

а новых не должно быть, в Core классе описаны все доступные свойства, при переопределении нельзя добавлять новые свойства, если в приложении нужны свои настройки надо делать свой класс, так будет даже удобнее

Я про это - нельзя перейти к определению свойства... попадаем в класс с дефолтами и нет возможности попасть на переопределенное свойство (с этим придется жить)

А че, енамы уже отменили?)

кого? чего?

Как енам динамически заменить? Его смысл в неизменности

Вот задача)

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

Я ничего не хочу. Смотрите задачу))) Я просто попытался решить, а не менять условие.

Ага. Чувак пишет свой енв с блекджеком и шлюхами вместо того что бы сидеть и работать. Ясно-понятно

ну ты непонятно описал, я задаю дополнительные вопросы