Both flouder99 and sauoq have good answers. The closures method is what I was originally looking for, but simply having a generic function works as well. I'm also trying to look at this from the perspective of who uses these functions. Is it better to have a lot of different function names, or one function that can take a lot of arguments?
Is it better to have a lot of different function names, or one function that can take a lot of arguments?
Generally, reducing the number of functions in your API is a good thing.
What do you mean by "one function that can take a lot of arguments" though? Functions shouldn't take too many distinct arguments, but it is perfectly fine for there to be many acceptable values for those arguments.
However, is it good for those arguments to be the names of the various tables and columns of the database? Or should that information be hidden/encapsulated by the API ?
One way or the other, there is going to be a large API. The requirements of the program dictate that. I mean, there are a large number of logical operations to do on the data. Whether there is a different function for each, or fewer functions with different arguments, it's still a large API. The syntactical appearance is different, but the the logical API is still there.
I think I'm leaning toward different function names, as explained elsewhere. Maybe this would be a good subject for another SoPW post.