Hi,
Hope this question has not been asked before, but I want to implement a
layer over top of DBIx::Recordset that basically gives me something similar
to the java.sql.DatabaseMetaData class.
A simple design is just to create a MyMetaData object and create a class
built above DBx::Recordset to override a couple of functions and do the
DBIx::Recordset call then do the additional stuff to populate the MyMetaData
object.
However, if I do:
package MyRecordset;
@ISA =qw(DBIx::Recordset);
1;
package main;
*set = MyRecordset->Search({'!Table' => 'blabla'});
...
I get this unfortunate effect of "Need DBIx::Recordset or setup parameter "
This is because there are a few places in the Setup functions of
DBIx::Recordset which directly test the object type :
elsif (ref ($arg) eq 'DBIx::Recordset')
This effectively precludes good behaviour for derived objects which will not
be blessed to DBIx::Recordset.
I have had to hack this stuff in DBIx::Recordset to make my class known, but
would prefer that this constraint was lifted from DBIx::Recordset.
For example, if the type returned from ref($arg) is a REF then go ahead and
do the assignment - if later things prove to be inconsistent then just maybe
the punter should stick with the vanilla DBIx::Recordset...
Perl does not provide much natural language support for utilising classes
(ie private constructors, pure virtual functions, un-overrideable functions
etc etc), so it can be quite difficult to use inheritance to share code.
Any thoughts are welcomed to working around this, and to any further
pitfalls I may discover!
Cheers, Alan
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
