why would you consider a class wrapper to autogenerate accessors to always be a bad idea?

They tend to encourage people to spread accessors everywhere throughout their classes and use them as a crutch for a broken design. Autogenerating mutators are even worse, because now you're not just grabbing internal data, but modifying it, too. You might as well be passing around a bare hash reference and tell everyone to do what they want with it.

Accessors (and to a lesser extent, mutators) can be used well, but they shouldn't be everywhere.

In fact, I'm starting to wonder if Class::DBI was actually a step backwards over Ima::DBI, which Class::DBI is based on. The reason is that Class::DBI exposes the entire database layout, while Ima::DBI performs some action based on the database using pre-defined SQL. I haven't come to a firm conclusion, though, and certainly many people have used Class::DBI to great success.

Regarding Class::DBI, I guess it depends on whether you believe that the module is providing object persistence, or transparent access to SQL-based records. If the latter, the current scheme makes perfect sense: you want your objects to have accessors for every column. If the former, then it's definltely broken for the same reason I made my comment up the thread. And most people seem to be using it for the latter, so that's why it's so successful. {grin}

-- Randal L. Schwartz, Perl hacker
Be sure to read my standard disclaimer if this is a reply.

One big advantage of accessors over passing round a hash is that if you mis-type an accessor name you get an error about an unknown method whereas if you mis-type a hash key you get a bug that may be hard to diagnose.

That's an advantage in Perl5, yes, but good class design is language-agnostic. There might be a language which provides locked keys for hashes by default, or perhaps you use one of the locked keys implementations in Perl (using a tied interface). Or maybe your language doesn't have hashes, but it has structs which are statically typed and serve the same purpose, and thus a compile-time error is generated anyway.

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated