Re: OO Architecture
[email protected] (Tim Bunce) Fri, 23 Sep 2005 21:11:02 +0100
| Newsgroups | perl.dbi2.dev |
|---|---|
| Message-ID | <[email protected]> |
On Fri, Sep 23, 2005 at 09:58:01PM +0200, Jochen Wiedmann wrote:
> 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. :-)
Thanks!
> >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.
> Basically, a typical DBI handle method could look like
>
> sub foo {
> my $h = shift;
> my $ah = $h->{ah};
> return $ah->foo(@_);
> }
Yeap. If we go with has-a then it'll be something like that.
(Except with the code will be auto-generated, the way DBI::PurePerl
does, or it'll be a common dispatch method.)
> (Error handling, logging and stuff like that omitted for brevity.)
>
> >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?
What examples of DBI subclassing can you show to prove your case?
How do Java developers get around the lack of subclassability in JDBC?
Tim.
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.