Re: OO Architecture

On Fri, Sep 23, 2005 at 09:11:02PM +0100, Tim Bunce wrote:
> > 
> > >But here's another, deeper, question that's more relevant at this point:
> > >"is subclassing the DBI actually important?"
> > 
> > I do strongly believe: It is.
> 
> Ah, you can't get away that easily! *Why* do you strongly believe it is?

[...]

> p.s. Those questions, and those in my previous email, aren't just
> directed at you Jochen, but everybody on the list. Come on guys, chip in.

I'd say that subclassing the DBI is not important at all ... if there
is some other way to achieve my goals (traditionally done by
subclassing).

What are the goals? To me, it is modification of certain aspects of
DBI's behaviour. Maybe you want some pre-preparsing or modification
of you statements (I have DBIx::ShowCaller on CPAN that adds a comment
line with the Perl caller information so that I can find it in Oracle
cache and see who sent me that query). Maybe you want different logging
support (I have a module that catches errors in production environment
(where no errors should happen so if they occur, it's really fatal)
and sends the error via email). Maybe you'd like charset conversion
to be done automatically but the usage to specific to bother
Tim with adding it into DBI core. Plus: maybe you want all three of
these at the same time and you want to keep you code tidy -- to have
three modules of which each provides single modification and which can
be used together or one at a time.

IIRC (but the last time I did DBI subclassing was like five years ago,
so the interface might have changed -- sorry Tim, if I'm missing
something) subclassing is done by setting RootClass. That's nice, but
how do you do multiple inheritance? One module modifying your parsing,
another one modifying your logging behaviour ... Currently you have to
create a single module that combines both behaviours, don't you?

I'd like to be able to say that a particular DBI->connect call should
give me vanilla DBI behaviour plus modifications specified by
DBIx::Module1, DBIx::Module2 and MySite::Module3. Where maybe
DBIx::Module2 modifies behaviour or DBI::connect itself.
I'd like to be able to plug in MySite::Module4 to existing $dbh, do
a couple of operations and maybe remove it later from the stack.

Is it callbacks I'm talking about? Handlers in Apache?

Being able to do something before, after and instead of a particular
DBI call. Being able to specify it either via class name, or using
individual references to subroutines that will be provided with
well-defined sets of parameters and will signal the result down the
stack. If I'm later going to make a subclass, by naming those changes
and putting them into a single module is just a nice final touch. But
in many cases, you actually do not need and do not want to subclass.
You just want a slightly different behaviour.

Hmmm. Did I get off-topic / miss what the subclassing business was all
about in the first place?

-- 
------------------------------------------------------------------------
 Honza Pazdziora | [email protected] | http://www.fi.muni.cz/~adelton/
 .project: Perl, mod_perl, DBI, Oracle, large Web systems, XML/XSL, ...
		Only self-confident people can be simple.