On Tue, 8 Jun 2010 12:49:16 +0100, Tim Bunce <tim.bu...@pobox.com>
wrote:

> On Tue, Jun 01, 2010 at 11:10:44AM +0000, Jens Rehsack wrote:
> > Hi Tim,
> > 
> > during the update of DBD::AnyData I hit some nice methods, which
> > Jeff has added to it, e.g. ad_get_catalog, ad_mod_catalog and
> > ad_clear.
> > 
> > These methods modify the meta data of the tables managed by DBD::AnyData
> > (DBD::AD) which will be done by DBD::File in future releases. So I talked
> > with Merijn to move the methods into DBD::File to have them common for
> > - DBD::AnyData
> > - DBD::CSV
> > - DBD::DBM
> > - DBD::PO
> > 
> > But now it comes ... typically driver private methods require a prefix.
> > This prefix depends on the driver name (so ad_* for DBD::AD methods, csv_*
> > for DBD::CSV methods etc.) - and it would be good for DBD::* users when
> > we keep/support this behaviour.
> > From  this  it  follows  that it's not done by moving the methods with some
> > refactoring to DBD::File and install them by their name in DBD::File - there
> > should be a better way.
> > 
> > Any suggestions?
> 
> I'm not really sure I understand the question/proposal/issues.

for all DBD::File methods/functions that are shared between ad_, csv_,
dbm_, and po_ (and maybe more in the future), the f_ method as provided
by the DBD::File (and subclasses) thould auto-magically map to csv_ etc

so when calling $sth->csv_get_attribute (), and DBD::CSV did not
implement csv_get_attribute (), but DBD::File implements
f_get_attribute (), the latter should automatically be called (and
cached).

> Tim.
> 
> p.s. The driver private methods only really require a prefix if you want
> to install them into the DBI dispatcher via install_method().


-- 
H.Merijn Brand  http://tux.nl      Perl Monger  http://amsterdam.pm.org/
using 5.00307 through 5.12 and porting perl5.13.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Reply via email to