Classes from folders Collector and Proxy will be moved to separate packages.
это вынесем, как будут готовы уже части дебагера и вьювера. пока удобно держать вместе
Оно у меня в прокси-контейнере юзается. Там уже в ПР полтора десятка классов новых и я прикидывал, чтобы с coupling все было в порядке нужно это все разбить где-то на пять пакетов. А еще коллекторы могут юзаться отдельно даже при неустановленном пакете дебагера, там свои кейсы есть. Так что отдельный yiisoft/collector - это весьма целесообразно.
ну та часть, которая в Debugger'е теперь лежит вообще сделано не правильно, да и завязана на все реализации от yiisoft, но не очень явно: $container->addProvider, $listener->attach, $enabled = $params['debugger.enabled']. это всё конфигурации, и от них желательно избавиться в классах. передавать в параметрах уже готовые флаги или сконфиженные классы
ну та часть, которая в Debugger'е теперь лежит вообще сделано не правильно, да и завязана на все реализации от yiisoft, но не очень явно: $container->addProvider, $listener->attach, $enabled = $params['debugger.enabled']. это всё конфигурации, и от них желательно избавиться в классах. передавать в параметрах уже готовые флаги или сконфиженные классы
Та это все понятно, просто ищу пути и направления, пока ничего нормального не нашел))
В каком смысле? О прокси-контейнере этот пакет ничего не будет знать. В нем есть коллектор, у которого есть интерфейс с которым работает прокси-контейнер.
я сейчас посмотрел на код в мастере, и там есть такая же возможность задавть свой LogCollector/EventCollector, просто передав нужный в конструктор дебагера
это будет еще одной реализацией CollectorInterface?
если да, то оно может быть создано и сейчас. делаешь новый коллектор, подменяешь по ссылке аргумент $container, и подменяешь реализацию ContainerInterface на свою обёртку. готово, у тебя прокси контейнер