Christopher Hicks writes:On Tue, 26 Oct 2004, Smylers wrote:
... DBIx:: should be for things that are generally usable with DBI, where the "I" is independent ...
I agree with Chris much more than Smylers here, but if we go along with Smylers perspective for a minute then we need /some/ hierarchy for "database-related things that aren't avertising they're using DBI for some reason".
Why?
So that database-related things are kept together.
There are several top-level namespaces on Cpan that are simply the names of some external software that the modules in that namespace work with.
We have that for Oracle and Sybase, but does that make it easier on people trying to find related things? If something is database related and based on DBI I'd like to see it in DBIx. If its something that is database related and its based on some other interface it should be in "Database::" or "SQL::"
In particular, there are already many in the MySQL:: namespace: http://search.cpan.org/search?m=module&q=MySQL&s=1&n=20
Precedent means a lot more in a court of law than it should elsewhere.
It may not be a perfect namespace, but it certainly isn't terrible, it's unambiguous, and surely it's better to keep on using it for similar 'MySQL'-related modules than to put new ones elsewhere (or persuade all the existing ones to move)?
I don't think we can persuade all of the existing ones to move, but if we had a general agreement that database related modules should be in a handful of namespaces it would seem to be advantageous. I'd love to see see Alzabo. MySQL::Backup, and the other DBI-based modules with strange names paces all go in DBIx while the other things (oraperl, postgres, etc.) go into Database::. We have Spreadsheet:: to take care of spreadsheets.
The more I think about it DBIx would seem to be the winning place for this sort of thing.
When I read Mark's message I realized his point is what I'd been wanting to say in the first place; so the more _I_ think about it, the more DBIx:: seems like a completely inappropriate place for this module!
How is doing a database backup any less of a DBI extension than DBIx::Copy or DBIx::HTMLView?
-- </chris>
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare
