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.

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

    package MyCorp::DB::Object::Cached;
    use base 'Rose::DB::Object::Cached';

    package MyProj::DB::Object;
    use base 'MyCorp::DB::Object';

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

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

> 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.

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


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


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