Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Wed, 23 Jan 2008 13:01:21 -0500 John Siracusa [EMAIL PROTECTED] wrote: JS Yeah, [Class::C3] simplifies this situation greatly (at the cost of JS another dependency and possibly a new set of bugs/issues :) I really think you should put that in the RDBO::Cached docs, with caveats and all, but at least point people to it. Ted - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Jan 23, 2008 10:55 AM, Ted Zlatanov [EMAIL PROTECTED] wrote: 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 should work as long as My::DB::Object doesn't define its own custom load(), save(), or forget(). 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. There's really no supported/unsupported distinction here. If the public methods resolve in the way you want, then you win :) I think the Class::C3 solution is the best approach, thanks for suggesting it. Yeah, that simplifies this situation greatly (at the cost of another dependency and possibly a new set of bugs/issues :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
Re: [RDBO] inheriting from RBDO::Cached vs. RDBO question
On Jan 22, 2008 11:28 AM, Ted Zlatanov [EMAIL PROTECTED] wrote: On Mon, 21 Jan 2008 13:24:49 -0500 John Siracusa [EMAIL PROTECTED] wrote: 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: JS http://search.cpan.org/src/JSIRACUSA/Rose-HTML-Objects-0.552/lib/Rose/HTML/Object.pm That's a pretty nasty hack. Really, I think this should be a standard mixin Mixins are a pretty nasty hack. That code is just automating them :) Anyway, when building a single super-base class, I don't think it's particularly ugly to set up your class hierarchy and then yank in a particular method (say, init_db()) from another specific class. Or like I said before, you could go the Class::C3 route and avoid all this. 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. If you look at the code you'll get an idea of why it's in its own package. Yeah, it certainly could be made as a series of helpers with some modification, but doing it as a class allows for introspection (is this a cached object?) and better isolates any potential ugliness or complexity of the caching implementation. 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 :) It'd be unlike other helpers in that it'd have its own significant data structures off to the side (the cache itself) and it'd modify existing methods rather than adding new ones. It sure seems like a subclass to me. (Actually, it's perhaps more like a Perl 6 role but you know... :) -John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Rose-db-object mailing list Rose-db-object@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rose-db-object
