Re: PDO meeting in Cancun

Just a quick response to Lukas' blog entry.

I know Lukas would love to see things work a little differently in PDO, but there are good technical reasons why things are the way they are now. Here are some reasons in random order:

• It's impossible to build a magic database abstraction layer that works for everything
• PDO is data-access abstraction (not database abstraction). The primary goal is to make things similar enough that you don't end up cursing at the API. The abstraction is also present for the benefit of extension developers, making it less of a headache to build database drivers for PHP.
• No two underlying database client APIs are the same
• Most don't separate the concept of a prepared statement handle from a result set.
• Most overload functions like RowCount() to have the dual meaning that Lukas mentioned.
• the MySQL client API is a bad example of a typical database client API. Don't use it as your baseline for comparisons to the others.

A closing comment regarding the naming of the PDO methods; I didn't follow Lukas' "Unofficial subjectively observed key design principles"; the PDO APi just happens to follow the APIs of the underlying database clients because it means that PDO doesn't have to do too much work on top of those APIs, and because those particular APIs have been designed by people that live and breathe databases. I like to avoid the NIH (Not Invented Here) syndrome where I can (although I confess that I do succumb to it from time to time). Regarding the length of the method names, I don't believe that they should be as short as possible, but don't believe inOverlyLongNamesForTheSakeOfMakingTheCodeReadLikeEnglish().