Although not strictly subclassing, I'll mention DBIx::Interpolate:
http://search.cpan.org/dist/SQL-Interpolate/lib/DBIx/Interpolate.pm
The Description section of the POD says it all: << DBIx::Interpolate
wraps DBI <http://search.cpan.org/perldoc?DBI> and inherits from
SQL::Interpolate
<http://search.cpan.org/%7Edmanura/SQL-Interpolate-0.31/lib/SQL/Interpolate.pm>.
It does nothing more than bring SQL::Interpolate behavior into DBI. The
DBIx::Interpolate interface is very close to that of DBI. All
DBI-derived methods look and behave identically or analogously to their
DBI counterparts. They differ mainly in that certain methods, such as do
and select.*, expect an interpolation list as input:
$dbx->selectall_arrayref( "SELECT * from mytable WHERE height > ", \$x);
...DBIx::Interpolate also [transparently caches statement handles]. >>
> Was subclassing the DBI a good approach?
No. DBIx::Interpolate does use DBI for the bulk of the
implementation/behavior, and their interfaces are conceptually similar.
However, the interfaces are not compatible in a strict OO sense: they
have different parameter list formats and prepare() does not return a
DBI statement handle but rather an abstraction (a set of statement
handles). For these reasons, a wrapper was used. Moreover, I
copied/pasted (and adapted) sections of DBI code into DBIx::Interpolate
in order to provide analogous behavior for the various
(fetch|select)(all|row)?_(array|hash)(ref)?|do methods.
> Where there any problems?
The need to copy/paste code.
>Could it have been done well/better some other way?
Likely, but I will need to further investigate. OO programming might
not offer a good solution though.
--davidm
Tim Bunce wrote:
I'm interested to hear stories of people who have subclassed the DBI,
or used modules that subclass the DBI.
Was subclassing the DBI a good approach?
Where there any problems?
Could it have been done well/better some other way?
Thanks!
Tim.
