On Tue, 22 Jan 2008 17:17:18 -0500 "John Siracusa" <[EMAIL PROTECTED]> wrote:
JS> Anyway, when building a single super-base class, I don't think it's
JS> particularly ugly to set up your class hierarchy and then yank in a
JS> particular method (say, init_db()) from another specific class. Or
JS> like I said before, you could go the Class::C3 route and avoid all
JS> this.
So I'd inherit from My::DB::Object first, then Rose::DB::Object::Cached?
That might work if I understand the docs correctly. Have you done this
before, and are there any things I should beware? If it's a supported
solution to my problem, it should be in the docs because I'd imagine at
least a few more people will run into it.
JS> If you look at the code you'll get an idea of why it's in its own
JS> package. Yeah, it certainly could be made as a series of helpers with
JS> some modification, but doing it as a class allows for introspection
JS> ("is this a cached object?") and better isolates any potential
JS> ugliness or complexity of the caching implementation.
I agree: theoretically you're right. Practically it's hard for the user
that wants to mix cached and non-cached objects because of the standard
Perl inheritance. I think the Class::C3 solution is the best approach,
thanks for suggesting it.
Ted
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Rose-db-object mailing list
Rose-db-object@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rose-db-object
