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.

The DI container will call these methods when the class is registered to find out the class meta-information. Using this approach, I've ported Marcus's phemto code to php4. The tests run pretty much unmodified. Would be interested to hear what other people think of this approach.

This is a problem I've been having: is there a good way to associate meta-data with classes and objects in PHP4 and/or 5?

This is probably the one thing that makes DI quite undesireable in zend1. The hassle of providing the meta-data kind of outweights the gains. Perhaps some ingenious code-generation could easy the pain a bit, but I remain sceptical.

This is probably the one thing that makes DI quite undesireable in zend1. The hassle of providing the meta-data kind of outweights the gains. Perhaps some ingenious code-generation could easy the pain a bit, but I remain sceptical.

I thought the approach I'd used was quite neat :-). I don't think it would be a hassle, even for complex code. The description of the class is right there in the code where it should be. Of course it's not as elegant as having it built into the language, but good enough IMHO. I disagree that the hassle is bigger than the gains. Admittedly, I haven't tried this in a real application.

Why not add the extra information at the registration stage? One of the nice things about DI is the minimal impact it has on the components. Having to implant a reflection API could be a big deal, especially with PHP5 "around the corner".

By adding meta to the registration, or directly to Phemto, the application writer and framework writer that registers the component has to take care of it. On the other hand, these are the same users thet have to manage the high level stuff anyway...er...such as PHP5 migration .

Specifying things explicitly would also be upward compatable with PHP5 and might even allow some sort of override capability in PHP5 where it would fill in suing introspection everything not provided explicitly.

oh, i've completely misunderstood it then. The constructor must've confused me, since at the time registering to a DI there is usually no object creation, i believe. What did you mean by passing 'new Php4()' then?

still, makes me think. How about if the actual injection would be a class that would hold the injected classes' name along with additional meta info.

then the instantiation would be defered to a factory that would create a proper Injection instance, depending on the version of php. For php5, it would override the passed meta-info with the actual dependencies.

I am just thinking out loud, i guess there's at least too much overhead, if not something worse wrong here

come to think of it, there is no need for an object to be returned from Injection::Create(), there's just the three pieces of information. But still, this static method could be useful for php 4-5 compatibility.

Sorry, I've confused you further by my typo above. The object has not been instantiated at that point and isn't as part of the registration process. It just declares to the injector that this class can be substituted for an interface.

Regarding using "new" here, I don't see a problem. I see it as a more general...

PHP Code:

$injector->register(new Declaration('Class', ...));

...where you could add overridden parameters, namespaces for instantiation or whatever. It's a hook for arbitrary extension. Factories are limited to the ideas of the Injector writer.

The Injector::create() method is a factory of which you speak. That's normally called by the framework to fulfill the interface of course. Nothing to do with the set up of the injector.

I thought the approach I'd used was quite neat :-). I don't think it would be a hassle, even for complex code. The description of the class is right there in the code where it should be. Of course it's not as elegant as having it built into the language, but good enough IMHO.

Actually, after looking over it a couple of time, I'd like to withdraw my previous statement. Your solution is indeed quite elegant, because it looks a lot like it would in php5.
I think my reaction came from an inherent defensemechanism against people trying to simulate language features. (Such as when people want classes and inheritance in javascript).
In your case it fits nice in though, since the feature exists in php5.

And I do prefer yours over the one marcus posted below, even though that has gotten more attention for the last couple of posts.

Sorry, I've confused you further by my typo above. The object has not been instantiated at that point and isn't as part of the registration process. It just declares to the injector that this class can be substituted for an interface.

Regarding using "new" here, I don't see a problem. I see it as a more general...

PHP Code:

$injector->register(new Declaration('Class', ...));

...where you could add overridden parameters, namespaces for instantiation or whatever. It's a hook for arbitrary extension. Factories are limited to the ideas of the Injector writer.

Let me get this straight. At the time of di-registration someone must dig for (with reflections in php5) or get (passed exclusively in php4) class instantiation information (dependencies).

This could be either the injector itself (Phemto), or the Dependency that you introduced. In latter case, the Injector relies on that it already has all information it needs, so it's role is purely to lookup classes and instantiate them.

If you meant the former, I've understood you the first time already. I just tried to be a wise guy and went complicating things up, as always. I tried to introduce a factory that would dig information about a class, and return it as a purely data-holding Dependency object for the Injector.

Originally Posted by lastcraft

The Injector::create() method is a factory of which you speak. That's normally called by the framework to fulfill the interface of course. Nothing to do with the set up of the injector.

Actually I was talking about a Dependency factory briefly explained above, but it's completely unnecessary.

Let me get this straight. At the time of di-registration someone must dig for (with reflections in php5) or get (passed exclusively in php4) class instantiation information (dependencies).

Some precalculation may happen, but mostly it happens when the instance is created to allow overrides. Part of the idea is that you can place an intercept between choosing a class/interface and actually instantiating it. It breaks the "new" operator into two pieces if you like.

Once this trick gives you a foot in the door, you can bring in a truck load of cleverness. These include service location, lifecycle (whether to use an existing instance, a persistent instance) and decoration.

Anyway, that tiny litle step gives it a lot of power. As someone commented on another thread, you don't reallt get DI until you first see a need for it in the code you are writing. Once you spot it the first time, that opens the floodgates.