Good point. I was more meaning in contrast with Micha's suggestion, and the division of the three there are, not necessarily within that third single arg. But that wasn't at all clear.
When I first started to float an implementation of this with Adobe (I was not the only one doing so), I could see a case for this division within the "config" stuff:
* datasource: datasource, user, password, dbtype
* cache: cachedAfter, CacheId, cacheRegion, cachedWithin
* connection: blockfactor, fetchClientInfo, maxRows, timeout, result (not sure about the latter)
debug hanging by itself. Does it make sense to stick it in datasource or connection? [shrug]
So that gives this function signature:
Query queryExecute(String sql[, Struct/Array parameters[, Struct datasource[, Struct cache[, Struct connection[, Struct ormOptions]]]]])
Six args is quite a lot. But I guess only the first one is required (even if the second would always been strongly recommended).
But there is still a case for one argument which is all the config options. Like it or not, they do have the cohesion that they are all config for how the query execution is performed.
Well that's a bit of a logical fallacy at work there, innit? The popular position is not necessarily the most informed one. And especially in stuff like this, I find the popular position is often pretty wrong-headed.
I'm also not sure yer actually right about that. Still: no point dwelling on made-up alternate realities is there?
Also bear in mind that the current implementation did not pop into existence of its own accord: an active decision was made to implement it the way it was. And - thusfar - Micha's been the only one I've seen questioning it, and for pretty dubious reasons. On the whole everyone's been pretty pleased with the implementation as far as I can tell, except for the reasonable case that it's still not as tidy as