Re: Changing Modules in Bad Code

in reply to Changing Modules in Bad Code

the more challenging (but maybe easier, too??) of writing my own "Postgres" module that actually acts as a *wrapper* to the current DBI module

I don't think this is a good idea. To access a Postgres database using DBI, you'd need the DBD::Pg module. This converts standardised DBI calls to the Postgres API. I assume that the existing Postgres module looks a lot like the Postegres API (that's how most of these older database access modules work). Your suggested module would therefore convert Postgres API calls to DBI calls, only to have DBD::Pg turn them straight back again. That pretty much seems to defeat the object of using DBI to me.

--
<http://www.dave.org.uk>

"The first rule of Perl club is you do not talk about Perl club."
-- Chip Salzenberg

Comment on Re: Changing Modules in Bad Code

Replies are listed 'Best First'.
Re: Re: Changing Modules in Bad Code by hardburn (Abbot) on Jul 09, 2003 at 15:26 UTC
Looking at it from an engineering point of view, you're right. But it's possible that development time is more important than making it look right, in which case modifying the existing Postgres module will probably take less time. ---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident. -- Schemer Note: All code is untested, unless otherwise stated	[reply]

Replies are listed 'Best First'.

Re: Re: Changing Modules in Bad Code
by hardburn (Abbot) on Jul 09, 2003 at 15:26 UTC

Looking at it from an engineering point of view, you're right. But it's possible that development time is more important than making it look right, in which case modifying the existing Postgres module will probably take less time.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

[reply]

In Section Seekers of Perl Wisdom