in reply to Best practice with polymorphic constructors
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
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