Простой блог быдлокодера

За кэш отвечает класс Doctrine\Common\Cache\CacheProvider и его потомки.
Там можно что угодно использовать в качестве хранилища.

reaper, я просто думал что оно несколько иначе работает.

Т.е смотри, у нас на пример есть билдер определенний контейнера и мы пишем что то вроде:

return [
    IConnection::class       => Di\Singleton(Connection::class),
    ICache::class            => Di\Singleton(Cache::class),

    IAuthorRepository::class => Di\Transient(UserRepository::class, [
        Di\Link(IConnection::class), Di\Link(ICache::class)
    ]),
];

Которое кешируется в единый класс расширяющий динамический контейнер:

class Container extends Framework\Container
{
    protected $Framework_IConnection;
    protected $Framework_ICache;

    public function getFramework_IConnection() {
        return $this->Framework_IConnection ?: $this->Framework_IConnection = new Espresso\Connection();
    }
    public function getFramework_ICache() {
        return $this->Framework_ICache ?: $this->Framework_ICache = new Espresso\Cache();
    }
    public function getIAuthorRepository() {
        return new UserRepository($this->getFramework_IConnection(), $this->getFramework_ICache());
    }
}

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

class Container
{
    public function resolve($alias)
    {
        if (method_exists($this, $method = 'get'. str_replace('\\', '_', $alias))) {
            return $this->{$method}();
        } else {
            return $this->dinamicLookup($alias);
        }
    }
}

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

З.Ы: вот если бы ещё и Closure таким образом можно было кешировать из памяти в код. Это наврено надо тянуть какой нибудь PHP Parser или как он там называется, что бы анализировать что там в лямбде за код, ну или вобще от них отказаться в данной реализации.

L!MP, Не, он там тупо смотрит в кэш, если в кэше ничего не нашлось, пишет туда. При каждом запросе надо будет заново создавать билдер, грузить определения и создавать контейнер.
Генерируемые конечно круче будут.

reaper, вооот. Надо бы по курить эту тему и м.б что-то придумается по поводу closure. Хотя быть может они и не сильно нужны.

L!MP, Ещё как нужны. Вот есть у меня например класс, который принимает в конструктор какой-либо параметр, который не лежит в контейнере. Что прикажешь делать? Костылять и пихать в контейнер далеко не лучшее решение. Я собирался поиграться с анонимными функциями. Может что-нибудь и придумаю.

Гг. пока только сам контейнер реализовал.

reaper, так сделать просто билдер определений более функциональный и все. Например:

IBaz::class => singleton(Baz::class)
    ->withConstructorPatameter('something')
    ->withMethodCall('setSomething', ['something']);

Если я тебя, конечно, правильно понял.

L!MP, Нее. Вот:

\DI\factory(function ($c) {
    $config = $c->get(Config::class)->load('routing.yml')
    return new Router($dispatcher, $config);
});

reaper, ясно. Ну тогда х.з, нужно как то эти замыкания в статический контейнер переносить.

Вот набросал немного: https://gist.github.com/Kilte/ ... d7071