Quote Originally Posted by oddz View Post
The problem with hard coding different find methods is that the model file must be changed.
I generally have one mapper per domain object, so that's not a problem.

Quote Originally Posted by oddz View Post
By providing a interface to do anything at run-time the model never needs to be touched. Furthermore, routing everything to one method to find everything supports the DRY principle.
Really? Lets say on one page you need to find a user by ID:
user::find(array('id'=>89)); And then on another page, you need to find a user by another ID. How many times did you write this?
PHP Code:
Twice. Even in a simple case like this, I'd rather duplicate a method name (getById()) than an array key. If I ever need to rename that method, I'm going to get a bunch of errors telling me exactly what code where used a nonexistent method. Yeah, it's a simple example, but the more you do at runtime, the more duplication you have.

Quote Originally Posted by oddz View Post
How the model finds what it is looking for is best a decided at run-time in my opinion. Otherwise, you end up with a bunch of similar methods that aren't very flexible.
I disagree. A datasource object should only need enough information to correctly identify what it needs. In the case above, the id is all it needs. Considering how common finding by an ID is, I don't need to tell it what field to match.

Quote Originally Posted by oddz View Post
Actually the finder does have a interface. The array is converted by the system though. As does the model
Internally. That doesn't help me out when trying to figure out what to pass to your system to get it to do what I want. If I can't use your methods, what good is the interface to me? I'm stuck working with nested arrays. An array inside an array is probably fine, but any more than that is a pretty big indicator you have some refactoring to do.