If you move the redis connection out of the constructor and only establish a connection when a method that will interact with redis is actually called, then everything would work as you’d expect without the “invisible” downside of having to dig into the underlying class to see the attribute and understand its implications on the Laravel container.

Laravel container is already extremely powerful and factory-driven in the sense that only when a class needs to be instantiated it incur overhead, so I don’t think this is a positive change to the framework overall.

In your controller example, one could use method injection instead of a constructor injection:

publicfunctionshow(RedisService$redisService,int$productId):JsonResponse{$product =$redisService->getProduct($productId);// …}

Furthermore, I agree with@deleugpn, and can't figure out places where this would bring more value, than what we already get from Laravel's container.

I would agree that Lazy Objects support would be great, especially for services that require a huge set up when instanced.

The main problem I have with Lazy objects is testing. Are these completely compatible with Mockery?

@deleugpn Thank you for the feedback :) I partially agree with you. However, I don’t fully understand what you mean by "only when a class needs to be instantiated it incurs overhead" - could you elaborate?

@rodrigopedra Thanks for the feedback as well. It's great that you and@deleugpn provided an alternative approach to the example - it makes sense. However, it's just a simple example. I'm also considering a case where we have a class overloaded with dependencies, such as Carbon.

Let’s be honest - Carbon is a heavy class and sometimes it can even freeze the IDE.

I’m referring to lazy loading for such a class (of course, this is just a quick example):

class ArticleService {publicfunction__construct(publicCarbon$createdAt,publicCarbon$publishedAt,// ...    ) {    }}

@DarkGhostHunter could you explain where the claim that "The main problem I have with Lazy objects is testing" comes from? :D I don’t see any issue with testing - a Lazy Object gets initialized upon interaction and behaves like a regular object. You can see that in the tests in this PR - take a look, there’s an assertInstanceOf on the lazy object. If I misunderstood the question, please clarify or provide an example - I’ll try to test it and share some feedback ;)

@DarkGhostHunter could you explain where the claim that "The main problem I have with Lazy objects is testing" comes from? :D I don’t see any issue with testing - a Lazy Object gets initialized upon interaction and behaves like a regular object. You can see that in the tests in this PR - take a look, there’s an assertInstanceOf on the lazy object. If I misunderstood the question, please clarify or provide an example - I’ll try to test it and share some feedback ;)

Nevermind, I though they weren'ttesteable. Keep up the good work.

Let’s be honest - Carbon is a heavy class and sometimes it can even freeze the IDE.

Never heard of this problem before, to be honest.

I'm also considering a case where we have a class overloaded with dependencies, such as Carbon. [...] I’m referring to lazy loading for such a class

I get the idea. What I don't get is the benefits compared to what the container already does.

It already runs a factory function only when needed. And you can use method injection, or theapp() helper, to narrow down a dependency's scope.

But maybe I am missing something. Let's wait on the maintainers.

I don't feel a need for this feature, but maybe it will be better to define it in the constructor of the class where dependency is required (for example in the controller) and not in dependency class? Otherwise you can't define it in third party classes.

Can you elaborate a bit more about why we couldn't support it at the parameter level?

Can you elaborate a bit more about why we couldn't support it at the parameter level?

Sorry for the late reply@taylorotwell, but I was busy.

The obstacle is that we don't have access to the parent's attributes at the time of building the class that is supposed to be lazy.

I think the best example would be the code itself. I implemented Lazy handling at the attribute level, BUT in my opinion, there are a few trade-offs in the code that could be blockers – for example, the attribute passing chain.

Unless there's a better way to handle it and I'm just missing something 😄

Please check the latest commit - it contains the implementation I’m talking about:19bdded

Just an idea. Would a contextual attribute applied to the parameter work instead? I took the existing#[Give] attribute, but adjusted it so that it returns a lazy ghost:https://gist.github.com/ziadoz/f52653f37ae891b74fbdfc2d536abe06