Re: some MDB2 questions

Andreas Korthaus wrote:

Lukas Smith wrote:

The reason is that I focused on having a consistent API. This means that I dont to have certain parameters following certain others in all my methods calls.

So you do NOT care about a specific order of parameters? In this case it would be nice to have the parameters consistent to PEAR::DB API, I think.

I do care about the parameter order alot. Generally the query comes first. Then come the result types and then any other result related parameters in the entire core API. This is why I felt the position of the $result_types parameter I chose made absolute sense. However as it is kinda hard to determine what part is really the query in that method and what isnt it gets kinda blurry anyways .. so I do not care so much in this exact situation.

Then again, such a method isnt very consistent with the concept of abstraction anyways (which is why I placed it in the extended module). So if you feel that this is sufficiently consistent with the rest of the API I dont have a problem changing it.

For now I do not use these extra parameters. I try to switch a large existing application from PEAR::DB to MDB2 - without a wrapper. I think for the future it is nice to have a Database-API close to PDO-API.

Well thats the point I originally wanted to make. It makes no sense to design the MDB2 API by simply sticking in some additional parameters at the end. The end result is an API that is inconvinient to use when you actually want to make use of the additional features of MDB2. Obviously if you dont use them, those empty parameters may be a hassle. So to make it clear: I find it kind of irrelevant how hard it is to port from DB to MDB2 in terms of parameter orders. For the most part that is just a search and replace job. However I do try to keep things as API compatible as possible with PDO first and if that doesnt give me no choice than its PEAR::DB second. regards, Lukas