AM
стало лучше, чем сейчас, но в общем я не очень доволен, конечно, ситуацией в целом
Size: a a a
2020 August 10
AM
давайте пофантазируем на тему выкинуть совсем composer config plugin...
DS
давайте пофантазируем на тему выкинуть совсем composer config plugin...
В этом твоем варинате без плагина все будет работать
DS
А вообще можно сделать ConfigCollection и доставать конфиг в провайдере из нее
DS
А вообще можно сделать ConfigCollection и доставать конфиг в провайдере из нее
Эта коллекция легко мокается и сооответсвенно провайдер легко тестится. Нет завязки на плагин композера.
AM
Я не про конкретную штуку.
AM
Плагин скрывает от нас array_merge (это норм потому что по конфигу понятно +- что и куда мёржится) и собирает конфиги по пакетам. Вот эту вторую часть я начинаю любить всё меньше. Запускается не то, что мы написали. Отсюда вроде бы очевидные решения сделать какой-нибудь require 'events-web.php' или getenv('BLA') превращаются в те ещё костыли.
AM
И получается что большинство плюшек, которые даёт PHP в плане конфигов, не работают. PHP выполняется в момент сборки, а не в момент реальной работы.
AM
Есть, конечно, плюсы...
1. Очевидно, экономим на array_merge.
2. Потенциально мёржить пакеты всё-таки полезно для модулей.
1. Очевидно, экономим на array_merge.
2. Потенциально мёржить пакеты всё-таки полезно для модулей.
NO
Зачем его вообще билдить?
AM
Сообщение выше.
NO
Экономить время процессора?
AM
Пункт 1 - да.
NO
Я говорю не об использовании, а о сборке в массив
NO
То есть зачем конфиг нужен в виде массива в приложении?
NO
Можно объединять конфиги модулей без выгрузки в массив или в файл.
NO
Смысл у него тот же, что у бутстрапа.
Поднять всё необходимое для выполнения приложения и загрузить в объекты параметры, которые пользователь задал.
Тут нет принципиальной разницы, из массива мы дёрнули эти параметры, из файла конфига на диске, из памяти, из кеша, из констант класса.
Результат должен быть один и тот же. Так зачем привязка к файлам и массивам?
Поднять всё необходимое для выполнения приложения и загрузить в объекты параметры, которые пользователь задал.
Тут нет принципиальной разницы, из массива мы дёрнули эти параметры, из файла конфига на диске, из памяти, из кеша, из констант класса.
Результат должен быть один и тот же. Так зачем привязка к файлам и массивам?
NO
Каждый модуль может себе определить конфигурацию по умолчанию. Приложение может по необходимости всё это переопределить. Это всё может выполняться и в рантайме без проблем.
NO
Причём в виде нормального ООП-кода, а не массивов...
AM
Это замена декларативных конфигов на bootstrap и императивный конфиг. Радикальный вариант. Плюсы и минусы имеются.