First of all if you have reason to force code to be kept in sync (and keeping names/passwords in a config file is good enough reason for me) then you can partially alleviate the problem by putting in run-time sanity checks. For instance use Carp.pm and confess away if someone tries to connect that you don't know about, or if your config file doesn't have all of the information that you expect. While having no synchronization is best, a close second is to have rapid and detailed feedback upon breakage.

The second is about your indentation style. Yes, I know that a lot of people line up their indentation like that, but it is a maintanance hassle and comprehension is inhibited when indents go to 6 or more spaces in. My style is that if I am forced to move to another line, then I hit return and indent as I would for a block. YMMV on that, but consider how fast you indented way past 80 columns.

I don't like having the config file hardcoded into the module. What I use at work is a (sorry, proprietary) configuration module that avoids having any hardcoded file names. Rather have an access method of some sort which decides where to get the configuration from dynamically. Why? Well that makes tracking down all of the configuration files that you are using a lot easier. It makes it easier to separate development from production. (Each just picks up configurations with slight but significant distinguishing features - like what database to connect to.) And if you code the configuration logic correctly, you can have it pick up tyops in your configuration file.

<mydb>
  <config user="fooser" pass="foo" />
  <modify user="barser" pass="bar" />
</mydb>
[download]

HTH, --traveler

How secure is /Inetpub/Secure/foo.dat from other users on the server? The thing I like about Apache suExec is that I can set 'chmod 600 /Inetpub/Secure/foo.dat' to protect the contents while retaining cgi access. I've been setting up private ~/lib directories that way.

Can readers of the config be tricked into remembering too much? The polymorphisn you set up is a specialization to certain arguments of the stock DBI::connect method. Perhaps if your modules are sufficiently unreadable to the world, you can let each module take care of its own $dbuser and $dbpass using the same bareblocked closure you quote, but without the need for a synched config file. A module then knows its own secrets, and no other secrets are exposed to it.

Security is pretty often at odds with maintainability, and I think your question is an example of that. Apache suExec requires extra care. I wouldn't develop for it without taint on.

After Compline,
Zaxo

Why not do the following:

package Class::Parent;

sub new {
    my $class = shift;
    my ($args) = @_;

    my $self;
    unless (ref $class) {
        $self = {};
        bless $self, $class;
    } else {
        $self = $class;
    }

    my @keys = keys %$args;
    @{$self}{@keys} = @{$args}{@keys};

    # At this point, you have $self blessed into the right
    # class and with the right keys. Specifically, whatever
    # is needed for the DBI.

    # Do DBI thing.

    return $self;
}

package Class::Child;

use Class::Parent;
@ISA = qw(Class::Parent);

sub new {
    my $class = shift;
    my ($args) = @_;

    my $self = {};
    bless $self, ref$class || $class;

    $self->SUPER::new($args);

    # Do whatever else Class::Child needs

    return $self;
}
[download]

Now, if you wanted to get crazier, you could have each child initialize itself instead of in the parent. I originally thought of doing that, but decided to do it the simpler way, in case that was complex enough. You might want to move the hashslice assignment to the child and within the unless side (for the parent).

------
We are the carpenters and bricklayers of the Information Age.

Vote paco for President!