The smallest dependency injector?

[lastcraft]

Hi.

One expansion possibility was this...

$injector = new Injector();
$injector->registerAsSession(new Locator('MyInterface')); 

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...

$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.

Meanwhile, all of these lifecycle choices are interesting to me...

$injector->register('Class');
$injector->register(new Prototype());

$injector->registerAsSingleton('Class');
$injector->registerAsSingleton(new Class());

$injector->registerAsSession('Class');
$injector->registerAsSession(new Locator('Class'));
$injector->registerAsSession(new Locator(new Class()));

$injector->registerAsShared('Class');
$injector->registerAsShared(new Locator('Class'));
$injector->registerAsShared(new Locator(new Class())); 

Shared is shared memory in this case.

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.

yours, Marcus

[Ren]

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()).

[Azmo]

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?

[lastcraft]

Hi...

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 .

yours, Marcus

[Selkirk]

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.

[lastcraft]

Hi.

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:

1) Can instantiate with parameters...

// Infrastructure...
class Integer implements Number {
    function __construct($value) { ... }
}

// Application...
$injector = Injector::instance();
$injector->register('Integer');

// Domain or framework...
$injector = Injector::instance();
$injector->create('Number', 37); 

2) Searching by superclass...

// Infrastructure...
class UnsignedInteger extends Integer {
    function __construct($value) { ... }
}

// Application...
$injector = Injector::instance();
$injector->register('UnsignedInteger');

// Domain or framework...
$injector = Injector::instance();
$injector->create('Integer', 37); 

3) Singleton life cycle support...

// Infrastructure...
class Only {
    function __construct($message) { ... }
}

// Application...
$injector = Injector::instance();
$injector->registerAsSingleton('Only', 'Hi!');

// Domain or framework...
$injector = Injector::instance();
$injector->create('Only'); 

Note that parameters have to go in at registration time. There is no error checking for this yet.

4) Session lifecycle support...

// Infrastructure...
class MyCart implements ShoppingCart { ... }

// Application...
$injector = Injector::instance();
$injector->registerAsSession('MyCart', 'Our wonderful store');

// Domain or framework...
$injector = Injector::instance();
$injector->create('ShopingCart'); 

This doesn't work out of the box exactly. See 6 below.

5) Ability to use dependency injection to override the service locators...

// Infrastructure wrapper...
class MySessionLocator implements SessionLocator { ... }

// Framework...
$injector = Injector::instance();
$injector->register('MySessionLocator');

// Application...
$injector = Injector::instance();
$injector->registerAsSession('MyCart', 'Our wonderful store'); 

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.

6) Ability to add new registration methods...

// Infrastructure...
class DataMapperLocator implements PersistenceLocator { ... }

// Framework...
$injector = Injector::instance();
$injector->addRegistrationMethod(
        'registerAsPersistent',
        'PersistenceLocator');

// Application...
$injector = Injector::instance();
$injector->register('DataMapperLocator');
$injector->registerAsPersistent('Person');

// Domain...
$injector = Injector::instance();
$person = $injector->create('Person'); 

In fact the session system in the injector uses that technique. To install it you do...

require_once('phemto/injector.php');
require_once('phemto/session.php'); 

...and it appears by magic. This extra flexibility offsets the disadvantage of the injector being a Singleton somewhat.

Have fun .

yours, Marcus

[lastcraft]

Hi...

I can't give you any more rep,

Looks like neither can anybody else. Has the rep system been abolished?

yours, Marcus

[been]

Has the rep system been abolished?

http://www.sitepoint.com/forums/showthread.php?t=262139
Apparently

[Ren]

I'm still not sure where these fit in, in a PHP application.

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.

[lastcraft]

Hi.

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.

Don't know, but it was fun to write .

yours, Marcus

[arborint]

It seems to have most power as an enabler of a component approach.

I think after a standard error handling framework, a standard component framework is one of the essential ingredients for start getting some common foundations for MVC frameworks.

I've been too busy to look at your new code, but the new features look interesting.

[Ren]

One thing I did different was to use named arguments (via an array) when registring components. Not sure if gain much more flexibility, by giving it preference over the injectors' behaviour..

            foreach($constructor->getParameters() as $parameter)
            {
                if (isset($namedArgs[$parameter->getName()]))
                    $args[] = $namedArgs[$parameter->getName()];
                else if ($parameterClass = $parameter->getClass())
                    $args[] = $this->newInstance($parameterClass);
                else if ($parameter->isDefaultValueAvailable())
                    $args[] = $parameter->getDefaultValue();
                else if (!$parameter->isOptional())
                    throw new Exception("Missing parameter {$parameter->getName()} for {$locator->getClass()->getName()} constructor");
            } 

[lastcraft]

Hi.

Yeah, I think there is a lot that could be added, and probably has in Pico. I wanted the smallest and simplest start to explore the territory. All I need now is a project to use it in...

yours, Marcus

[Dr Livingston]

This does look interesting, doesn't it? If your going to throw something at it to see how well it stands, let us all know how you get on Marcus