Code contains many hints to what happens. Or at least, it should. I think removing the word that describes what happens is a bad idea.
Insert/select/update all make it very clear what goes on. "do" does not. It is like having a $data. Nice, but what kind of data? With do, I'd want to know *what* it does. Choosing based on something as subtle as argument differences isn't good enough, in my opinion.
There's a lot that can be abstracted in SQL. SQL::Abstract and DBIx::Abstract abstract the query into a method name and data structures, Class::DBI abstracts everything into objects. But always there is a way to see exactly what goes on.
The action should never be left out, and always be explicitly stated.
Please have a look at DBIx::Simple. It can use SQL::Abstract for some abstraction, but you'll always have to tell it what to do. It won't try to choose on its own.
Which brings me to another point: IF you decide to put this on CPAN, please make sure it is in the DBIx:: namespace. Don't invent a new root namespace just because you couldn't think of a name in DBIx::, because DBIx::Abstract was already taken. Be creative. (How about DBIx::Do?)
Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }
In reply to Re: RFC: Simple DBI abstraction
by Juerd
in thread RFC: Simple DBI abstraction
by Jaap
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |