[dev] [commits] Horde branch master updated. 104e3198ce8b82e1a469dce43420d2d6fa7e2a7d

Chuck Hagenbuch chuck at horde.org
Sun May 30 01:03:45 UTC 2010


Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> I changed the name as such simply because 'Horde_Db_Adapter_Base'  
>>> was confusing in that regard - that there was one DB object to  
>>> rule them all.  However, I see the need to have that name defined  
>>> as such for these type hinting binding cases.  I have no problem  
>>> renaming the Horde_Db_Base binder back to Horde_Db_Adapter_Base to  
>>> provide an easy injector to the default horde DB setup.
>>
>> This would save us from having to inject the db object explicitly  
>> and/or create binders for those classes where the dependencies can  
>> otherwise be automatically resolved, and the default horde db is  
>> desired. Though I do agree that the name could seem a bit  
>> confusing...
>
> For now, I've changed the binder name back to Horde_Db_Adapter_Base.  
>  Still think the naming is a bit confusing... but that confusion  
> will be alleviated once we start to document the list of binders  
> globally available.  Which is something we can probably start doing  
> now, since things are starting to settle down re: the way we are  
> using them.

Thinking about this a bit, what about adding a Horde_Db_Adapter  
interface, and having that be the binder name? That would make it  
easier to stub in other objects to satisfy dependencies too, rather  
than requiring inheriting from Horde_Db_Adapter_Base.

-chuck


More information about the dev mailing list