SetLazyNew

[jakeasmith]

I find myself writing this a lot:

$di->set('Foo\\Bar\\Baz', $di->lazyNew('Foo\\Bar\\Baz'));

What do you think about introducing a convenience method for doing all of that in one step?

$di->setLazyNew('Foo\\Bar\\Baz');

Perhaps it should even match the signature of lazyNew to allow passing in params and setters. I can PR this if its something you would accept.

[pmjones]

Setting the service to the name of the class, while something I suggest in MLAPHP as a transitional step, is not generally something I suggest for general use. I assert that you want to use a descriptive name for the service that is something other than the class name.

Having said that, I'm interested to hear more about the situation. Can you expand at all, or is that pretty much it?

[jakeasmith]

That's pretty much it. Just about all of our Di is handled via type hinting and we only very rarely manually request a service by name. It wouldn't make sense for us to use anything but the fully qualified class name here.

[pmjones]

Just about all of our Di is handled via type hinting and we only very rarely manually request a service by name.

This makes me curious -- are you able to share a paste of the DI code you're using? (I'm wondering about Service Locator stuff here.)

[jakeasmith]

It's all part of a larger package that I hope to open source sometime soon-ish. The gist of it is that we have a compilation step that analyzes our service layer, reflects each class to determine the required dependencies, and then sets up a unique factory (using this term loosely) per class injects the required dependencies.

Rather than instantiating a service class like new \PackageClass\GroupName\ServiceName we end up reaching it with something like $package_class->group_name->service_name().

So yes, behind the scenes the container is used as a SL, but it's all generated code that allows us to only see and work with DI.

[pmjones]

/me nods

I have to say that I am not eager to have service names doubling as class names. The fact that you're automating the setup portions makes me think that's the place to do this kind of thing; there, or in an extension of the Container class.