I guess I could try to suggest this as a PR to illuminate/container. I felt like doing it without going through Laravel's contribution hell, but you may be right about that too.

Well, consider that in symfony, you just need to mark a service as lazy and have ProxyManager as dependency (silently ignores it if unavailable).

In zf2 it got a bit more flexible, so you can do more things, but you'd register a custom "lazy" factory and have ProxyManager autoloaded (no need to swap out containers).

So yeah... laravel is pretty much the same. Actually, if illuminate/container is based on symfony/dependency-injection, then it's just a matter of wiring it up correctly.

illuminate/container doesn't use symfony's dependency-injection package in any way, all the reflection magic is coded right there.

I'll check the ProxyManagerBridge for ideas on how to cleanly implement it as a package. I feel that using namespace matching (instead of passing a lazy parameter) will be easier for the end user, and if you follow any sort of convention, you could have it configured once and forget about it all along.

In ZF2, is the implementation baked on the container, or is it a package?

In ZF2, is the implementation baked on the container, or is it a package?

Zend\ServiceManager is the DIC of ZF2. It looks pretty much like Pimple on steroids and it's available independently as zendframework/zend-servicemanager

lazy_services in ZF2 would be the same as matching with a collection of Cases here, but it doesn't need to be tied up to each service binding.
The same goes for the Definition->lazy = true on the ProxyManagerBridge.

I want this to be more pluggable, but Laravel's current architecture doesn't let you plug a different Application or Container instance... it's too late for that when you're actually using the container to instantiate all the ServiceProviders!

So I'm left with a Decorator, a Bridge or extending. L5 provides a contract for both classes so I could do a Bridge, but extending looks so simple...

but extending looks so simple

Yeah, but it won't be adopted either, heh

@Ocramius so... I had a small chat with Taylor on friday. He sees proxying out services from the Container as "Bad design", and when I tried to talk to him about decoupling the container and making it more extensible, he just disregarded me. In his mind, Container shouldn't be extensible and if a case arises, we should consult him directly.

Nothing surprising really, but very frustrating anyway.

@guiwoda I also believe that extending the container is not a good idea.

Consider looking at following PRs for inspiration:

• ProxyManager Bridge symfony/symfony#7890
• Delegate factories zendframework/zendframework#4145

Both those exponentially improve the containers, but they are not there as an extensibility mechanism.

The difference is that both sf and zf2 frameworks use Containers, while Laravel is a (extends the) Container.

In any case, if Container doesn't have an extensibility mechanism, and Taylor doesn't agree with lazy instantiation, then it's a no-go for this.

😞

@guiwoda @Ocramius
Can you guys explain please, what is so bad with Laravel is a (extends the) Container?
Also, as you can see, I've send issue to laravel/ideas repo, got likes, but no support/answers from core team. I might need to write them on twitter.

@guiwoda Does this package work? I'm very interested in lazy-loaded services.

@vladyslavstartsev the problem is inheriting from the framework DIC, like this package does.