внутри configuration я уже объявляю $container = new Container(); // some initialize return $container;

а, т.е. ты его не пихаешь в класс?

раньше делал так пока //some initialize не разрасталось

потом фигарил провайдеры

Extending a Container смотри в доке

http://pimple.sensiolabs.org/#extending-a-container

потом и количество провайдеров очень росло

и не очень понятно было что оно там инициализирует

потом смотрел http://php-di.org/

потом пилил свой)

пока не закончил но уже юзаю, даже кидал ссылку сюда, мне полезные замечания писали)

тебе пока extending a container хватит) потом разрастетесь, будете выбирать что то типо php-di (удобно что с помощью reflection грузит в нормальном коде ничего писать не надо)

главная проблема в pimple была в следующем

в большом проекте количество классов очень дофига

и там местами отчеты в phpexcel строились иногда

и чтобы отобразить что то простое иногда иницилизировались контейнеры в виде функций для phpexcel, phpoffice и тд (которое вообще только для отчетов было)

все было разложенно по провайдерам, но pimple все что в коде провайдера написано вызывает

мне хотелось чтобы определения (конфигурация) каждого контейнера лежала отдельно

например в разных файлах

запросили скажем $container['Magic'] подгружается Magic.php который возвращает объект Magic и этот объект отдается в то место где запросили)

мест, где вы юзаете контейнер как сервис-локатор должно быть крайне мало

поэтому единственное, что надо менять, когда переходите с одного на другой, это конфиг

он меняется за пару часов в самом худшем сценарии

когда прям ваще много классов

и легаси всякого

так что переход на php-di простая шляпа

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

так тут provider он не конкретный объект создает как бы с помощью service locator

он возвращает много объектов

которые проставляются в сам pimple

в этом то и беда

например

ничего не понял

provider в примере

создает много контейнеров внутри себя

много контейнеров?

http://pastebin.com/RRQY19Yu

вот такой ахтунг там в провайдерах

https://github.com/silexphp/Pimple/blob/master/src/Pimple/Container.php#L272

https://github.com/silexphp/Pimple/blob/master/src/Pimple/Container.php#L274

там просто вызывается функция регистр

каждый раз как регается провайдер и она создает всякие штуки

в небольшом проекте все ок

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

и причем больше половины из того что на определяли реально может не использоватся

сам код внутри функции конечно не вызывается

но сам процесс объявления имен всех объектов что есть в проекте

причем там не только твои классы объявлять, но и все что им необходимо из папки vendor

так понятней? или может я где то не так думаю

ну я слабо понял кейсы честно говоря

и такое ощущение, что делается что-то плохое

чего делать не надо

и с php-di вы это плохое делать перестанете просто ... профит

не совсем)

там в php di как раз загрузка идет по требованию

https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-11-container.md

вроде бы PSR-11 сейчас актуален

https://packagist.org/providers/psr/container-implementation

из всего что реально юзает (мне попадалось) это symfony или php-di.org

php-di кстате имплементет container-interop

который раньше чем psr/container появился

ERROR: S client not available

и container-interop сейчас просто наследуется от psr/container в основном интерфейсе

и container-interop сейчас просто наследуется от psr/container в основном интерфейсе

то есть они полностью совместимы?

ой

https://github.com/container-interop/container-interop/blob/master/src/Interop/Container/ContainerInterface.php

но там есть нюанс (не большой фейл)

но в целом да 100% совместимы

но там есть нюанс (не большой фейл)

в чем фэйл?

LSP нарушает?)

нет не настолько плохо)

хотя почти))

у них раньше в get было написано выкидывает NotFoundException ... и ContainerException (это интерфейсы но без префикса Interface на конце)

сейчас код в следующей версии они сменили тупо наследуются от psr/container/ConbtainerInterface

а там выкидываются экзепшены из psr/container которые

ну и эксепшены ж наследуются, так что все должно быть совместимым

а там выкидываются экзепшены из psr/container которые

по иерархии типов подходят

но в container-interop их Exception теперь от psr/container/exception наследуются

так что не должно нарушать LSP

но в целом container-interop/exception legacy хотя хз хз

по иерархии да

но они оставили лазейку непонятно зачем

ты опередил про наследуются, но с точки зрения ContainerInterface они никогда не вылятят)))

их для обратной совместимости скорей всего оставили

https://www.youtube.com/watch?v=p54Hd7AmVFU&list=PLGtm7trCCklGuwdTT6Ep7PPBnXTYFHBCX&index=1

[наброс] Верно ли я понимаю, что анемичные модели и active record - это вот прямо две крайности на одной прямой?

[наброс] Верно ли я понимаю, что анемичные модели и active record - это вот прямо две крайности на одной прямой?

что ты имеешь ввиду?

анемичная модель - это просто структура данных, которая описывает стэйт. И у тебя будут отдельные процедуры разбросанные по классам которые работают с этим стэйтом.

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

Именно. Скажем, я добавил в к этой самой структуре со стейтом методы peristency - теперь она умеет сама где надо сохраняться-загружаться. Она все еще анемичная?

Именно. Скажем, я добавил в к этой самой структуре со стейтом методы peristency - теперь она умеет сама где надо сохраняться-загружаться. Она все еще анемичная?

методы сохранения/загрузки вообще никак не влияют на "гемоглобин объектов"