Re: OO Architecture
[email protected] (Jochen Wiedmann) Fri, 23 Sep 2005 21:58:01 +0200
| Newsgroups | perl.dbi2.dev |
|---|---|
| Message-ID | <[email protected]> |
Hi, Tim,
> [Sorry for the delay in replying. I'm extra busy at the moment, not
> least because my wife is just a few weeks away from giving birth to our
> second child.]
excellent! :-) From personal experience, I wish you that we won't hear
very much from you in the next months and you enjoy being a happy daddy. :-)
> It's basically a distinction between:
>
> "An application DBI handle HAS-A driver handle"
> and
> "An application DBI handle IS-A driver handle"
I understand that distinction and, to be honest, there are of course a
lot of reasons for the former. In particular, the goal of a subclassable
DBI seems to me to be very worthwhile.
Ok, a new attempt. Let me reduce my original proposal to the following,
which is hopefully along the line of your previous posting.
Make the distinction between the actual driver handle and the DBI
handle simpler, explicit, and remove the magic. For example, give
the DBI handle an attribute "ah" (actual handle). Basically, a
typical DBI handle method could look like
sub foo {
my $h = shift;
my $ah = $h->{ah};
return $ah->foo(@_);
}
(Error handling, logging and stuff like that omitted for brevity.)
Personally, I'd be quite happy with that: At least, it would be
debuggable. :-)
> 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.
Jochen