Re: OO Architecture

On Wed, Sep 28, 2005 at 12:47:06PM +0200, H.Merijn Brand wrote:
> On Fri, 23 Sep 2005 21:11:02 +0100, Tim Bunce <[email protected]> wrote:
> 
> > > >But here's another, deeper, question that's more relevant at this point:
> > > >"is subclassing the DBI actually important?"
> 
> I don't think that's a fair question in this *dev* list.
> I think most of us know how to find workarounds for things
> that are currently impossible or hard to do in DBI

Yeap. That's partly why I asked on dbi-users. Once the replies slow
down I'll post a summary and see where that takes us.

> > > I do strongly believe: It is.
> > 
> > Ah, you can't get away that easily! *Why* do you strongly believe it is?
> 
> The easier it is to use and/or extend (and thus use) the DBI in general, the
> more feedback you/we get, and the better the final product will be.

Sure, the question is what balance to strike so that most people don't
pay a cost for the benefit of a few. (See my other reply about making a
separate base class for people who want to subclass.)

> Curious: how much feedback/patches did you receive on the DBI API from
> *users* as opposed to/compared to comments/patches/feedback from DBD-authors?

Hard to say now. Lost in megabytes of archives.

> > What examples of DBI subclassing can you show to prove your case?
> 
> I use these extension for ages:
> 
> # These three provide methods that prevent NULL values in the database
> # Oracle translates empty VARCHAR2 values to NULL :[[[
> 
> sub DBI::st::insert ($@)
> {
>     my $sth = shift;
>     $sth->execute (map { defined ($_) && $_ eq "" ? " " : $_ } @_);
>     } # insert
> 
> sub DBI::st::update ($@)
> {
>     my $sth = shift;
>     $sth->execute (map { defined ($_) && $_ eq "" ? " " : $_ } @_);
>     } # update

I'd argue that those belong in a _driver_ subclass. (Well, really, they
ought to be in DBD::Oracle as an option.) Patches welcome.

> sub DBI::st::getrows ($@)
> {
>     my $sth = shift;
>     my @r = ();
>     $sth->execute (@_);
>     while (my @f = $sth->fetchrow_array) {
> 	push @r, @f == 1 ? $f[0] : [ @f ];
> 	}
>     @r;
>     } # getrows

That's more generally useful - and it brings up a related issue:

Perl6 should make it much easier to 'compose' classes by giving a list
of Roles to be mixed in.  That could mean we'd see a lot of "DBI add-in
role" modules on CPAN, each adding just a few methods like that one.

That would enable application authors to pick-n-mix functionality.
At the moment it's hard to use multiple subclasses at the same time.

Tim.