On Mon, 21 Jan 2008 13:24:49 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote: 

JS> On Jan 21, 2008 8:34 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
>> I have some existing RDBO classes, all inheriting from a common
>> BaseObject parent.  If I want some of them to be selectively cached,
>> currently I have to create a BaseObject::Cached that inherits from
>> RDBO::Cached (I do this with a copy+edit, see below), and then each of
>> my classes can inherit from the cached variation.  The issue is that any
>> functionality in BaseObject will not be in my cached variation unless I
>> do a copy+edit.  I considered making BaseObject::Cached inherit from
>> BaseObject and RDBO::Cached but that seems like asking for trouble.

JS> I do this, and so far the world has not ended :)

JS>     package MyCorp::DB::Object::Cached;
JS>     use base 'Rose::DB::Object::Cached';
JS>     ...

JS>     package MyProj::DB::Object;
JS>     use base 'MyCorp::DB::Object';
JS>     ...

JS>     package MyProj::DB::Object::Cached;
JS>     use base qw(MyCorp::DB::Object::Cached MyProj::DB::Object);

JS> Obviously this doesn't allow methods in MyProj::DB::Object::Cached to
JS> override methods in MyCorp::DB::Object::Cached, but every arrangement
JS> has some tradeoff, thanks to Perl's left-most depth-first dispatch.
JS> (To get a better arrangement, you can always use Class::C3 or
JS> something...)

Ideally I should say

package My::DB::Thing::Cached;
use base qw/Rose::DB::Object::Cached My::DB::BaseObject/;

Otherwise I have to maintain two classes no matter what.  With this
approach, init_db() will be the default, which is not good.

>> Is there an easier way?  If a mixin could do it that would be great.  I
>> didn't see a way in the docs.  If not, maybe there's a better approach
>> I'm missing.

JS> When I need a mix-in, I just "make one" by manually importing methods
JS> as needed.  Writing a helper for this isn't too hard.  Look around
JS> line 560 of this file for an example:


That's a pretty nasty hack.  Really, I think this should be a standard
mixin, instead of forcing users to derive from a different class when
all that's changing is one small piece of the overall behavior.  What
methods are different in RDBO::Cached (I can look it up myself, but let
me know if there are any gotchas)?  I'll write the mixin code myself and
you can put it in RDBO::Helpers or I'll make a new CPAN module for it.

JS> IMO, all such things are fair in super-wide-usage base classes.  Do
JS> the complicated stuff in a very few well-defined places and reap the
JS> benefits broadly.

Agreed.  I'd like that place to be RDBO::Helpers, not My::DB::BaseObject :)


This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Rose-db-object mailing list

Reply via email to