Ну вот что-то пошло не так в контейнере. Сейчас мы можем поотлаживать реальный код. После PR, насколько понимаю, выполняться будет сгенерённый на основе реального код...
Ну вот что-то пошло не так в контейнере. Сейчас мы можем поотлаживать реальный код. После PR, насколько понимаю, выполняться будет сгенерённый на основе реального код...
Прокси легко отключается в конфиге. Он частично и используется для отладки. Нет никакого отличия от дебагера, который @xepozz наваял. Там те же проблемы будут если что.
Билдер контейнера оборачивает реальный контейнер в прокси, если он включен в настройках, если нет вернет оригинальный контейнер.
по билдеру тоже вопросы. зачем контейнер создает билдер через фабричный статический метод, если можно изначально делать new ContainerBuilder(), а метод build() вернет новый объект Container?
по билдеру тоже вопросы. зачем контейнер создает билдер через фабричный статический метод, если можно изначально делать new ContainerBuilder(), а метод build() вернет новый объект Container?
Чтобы не создавали родной контейнер через new Container
Do you want to override Connection in drivers packages?
not in db connection it will be abstract, and each package will have its implementation with its specifications, this to separate the tests and the packages correctly.
not in db connection it will be abstract, and each package will have its implementation with its specifications, this to separate the tests and the packages correctly.
why? which differences do you have in subpackages?
тогда new ContainerBuilder($container) хотя, если добавлять в композитный контейнер в котором уже есть контейнер с прокси и он включен, то он для него билдер создаст автоматом.
why? which differences do you have in subpackages?
Currently we have db, db-sqlite, db-mysql, db-pgsql, the idea in db must go all the common of data abstraction, while in the sub packages the specifications and actual implementation of each package.