[dev] [commits] Horde-Hatchery branch master updated. 2374bf4d0704a85d5ef81f88a9d9a5ef5dea0f15

[Chuck Hagenbuch]

Quoting Gunnar Wrobel <p at rdus.de>:

> As I only just started with the Provider I used in at a very few  
> places so far. So there will be no pain in moving to the Injector.  
> And I do like the Injector package as it is definitely *not* as  
> bloated as some of the other frameworks I looked at. Well, probably  
> depends on what you want to do with such a framework but the  
> Injector looks pretty good for what Horde might need.

Cool.

> Within Horde_Provider I used some magic methods (__get(), __set(),  
> __isset(), and __unset()) for convenience. The Injector currently  
> offers getInstance() and setInstance(). Is there a specific reason  
> for avoiding the use of __get() and __set()?

I've passed this along to Bob and James, and cc:ed them on this reply.

> When working with interface names I agree that I'd rather use  
> $injector->getInstance('Horde_Kolab_Server') than  
> $injector->Horde_Kolab_Server.
> Nevertheless the factory based Binder allows you to bind the  
> instances to any name. And for the unit testing I find it convenient  
> if you can use your mocks without requiring the use of a dependency  
> injector:
>
>   $injector = new stdClass;
>   $injector->some_mock = Mock();
>
> In any case the Injector should get a hasInstance() method. If you  
> agree I'll add it.

With hasInstance, what sort of logic would be checking it? It makes  
sense to me for completeness, but on second thought I'm not 100% sure  
what you'd use it for.

> I wrote a short summary on how to use Horde_Provider with Horde  
> (http://cvs.horde.org/co.php/framework/Provider/doc/Horde/Provider/usage.txt?r=2374bf4d0704a85d5ef81f88a9d9a5ef5dea0f15).
> Do you think it makes sense if I adapt it to the Injector and add it  
> to the package?

That would be fabulous!

Thanks,
-chuck