1) Configurataion file based connect parameters. These are be predefined before a connect is called or they can be loaded if absent at the time a connection is requested. 2) The user should rarely have to explictly interact with the connect statement, individual methods should make the connection when they are called.

I disagree completely. Configuration files should not be handled by a module. If the database has to be configurable, the user must provide for a function like that. Another reason I didn't create a dsn myself is that DBI's dsn is already useable, and I'm planning on writing a DSN-generator that uses the PEAR DSN scheme (mysql://user:pass@host/database and like that), so that you can use connect(pear('foo://bar...')).

OO Modules should NOT require external configuration files, but should get their configuration in the constructor method.

3) The names of the methods should state exactly what is being returned, this may increase the length of the name, but it will go a long way in making the script more mantainable.

You're right on that, but "hash" and "array" are acceptable, as a sub CANNOT return a real hash or real array. A sub can return a hash _reference_, or array _reference_. Besides, documentation removes all ambiguity, as the pod is very clear on what is returned.

That's another thing DBI does wrong: fetchrow_array returns a list, so it should be called fetchrow_list.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk