[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