The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

This makes the lifecycle orthogonal to the source. In particular it allows a class file searching algorithm to be added to the locator. The problem is how to fulfil a dependency from a session when the client of the class does not know which file to load...

PHP Code:

$injector = new Injector();
$injector->create('MyClass');

If it is the locator that is frozen in the session, rather than the object, then the locator can include the necessary file before unfreezing/instantiating the object. Of course this can happen behind the scenes as well, but allowing the user to write their own locators is an obvious flex point.

You could possibly have factories and persistence as well, but I like the idea of keeping things small. The real question for me is what is the smallest DI tool that is most useful for PHP. Pico seems to have a lot of namespace stuff that is just not needed for the single application slice that is a PHP script.

Hi.
This makes the lifecycle orthogonal to the source. In particular it allows a class file searching algorithm to be added to the locator. The problem is how to fulfil a dependency from a session when the client of the class does not know which file to load...

Doesn't __autoload() get called before an object gets pulled from a session?

Whilst __autoload() is limited, there does seem to be some discussion about remeding it.

SPL does have a more useful autoload mechanism, with spl_autoload_register() to registering multiple callbacks for loading classes. (Also has spl_autoload_unregister()).

Given that a PHP “program” is just a small slice of the application, the construction needs shouldn’t be that great, right? No need for complicated wiring and all that?

The wiring for a single request may not be all that complicated, but each request requires its own unique wiring. I think the true complexity of web applications lies in automating the generation of a different object tree for each request.

@Marcus: you've built a simple Dependency Injector, and it might very well have advantages over other solutions. But exactly which problem are you trying to solve? Which (common) forces in web applications are driving you towards this solution?

you've built a simple Dependency Injector, and it might very well have advantages over other solutions. But exactly which problem are you trying to solve? Which (common) forces in web applications are driving you towards this solution?

I have absolutely no idea. It is just a half formed feeling that there may be something to this new "craze". Hence why I wanted to play with it to see what turned up. If I write the smallest one I can then I can see it's usefulness evolve as I add features. Or not. Basically I haven't got a clue .

I was approaching things from a different perspective. I've been refactoring my code to rely more and more on manual dependency injection, expecting that the role of a container would eventually become obvious.

I have done a little more work on the code as a bit of fun. The injector now has a Singleton interface, and you have a little more control over parameters and the lifecycle. It still searches by interface, but it now caters for some of the day to day practicalities. Best to look at the tests for the detail, but here are some of the new features:

This means that you can have your own session handlers for example. Basically the dependency injector uses dependency injection internally. Makes the code a little difficult to understand though, even though it's not much more than 100 lines.

I did implement one after the first on this thread, and drop in into a small prototype application, so it basically wires the low level database access object, to the dao factories, to the services.
Havent gotten around to writing a config file reader of somesort that registers the implementations with the injector, which seeming is the main use for these things.

I get the feeling they (Injectors) were created in java, because of java's descent into configuration hell, where in places seemingly write more XML than actual java.

Since putting together this...well...plaything, I have had my eyes open for uses. It seems to me you either have to have a big app. with several separated component authors or be doing some type of framework. It seems to have most power as an enabler of a component approach. I could imagine the WACT or Seagull projects using it for example, as the plug-in architecure is central.