And the OP design makes me shake my head in wonder as to why one would want this behaviour.
I can think of some times in the past when something like this would have been useful to me. Having non-primitive ordered pairs can sometimes be useful.
YAGNI simply cannot apply to public APIs. For example, Tim Bunce may not need all the APIs provided by DBI, but users of DBI may, among all of them, need those APIs. Different APIs that do things the same way, but return their results differently (selectall_arrayref vs selectall_hashref vs ...) aren't "needed"
I think we're using different definitions of YAGNI. YAGNI isn't about having minimal interfaces. It's about avoiding the expense and potential error involved in writing code before a need for that code has been demonstrated.
| [reply] |
No, I think we're using the same definition. I'm just pointing out that the developer of "it" may not be the user of "it" especially as it pertains to APIs.
I understand YAGNI's usefulness for in-house software, or internal functions inside software that will escape to users' machines. Only write what you need, when you need it.
The problem is that if Tim Bunce never needed selectall_hashref, who would write it? Would each user of the DBI that needed it then write it, and we would end up with about two dozen different selectall_hashref's, with a half-dozen different sets of parameters, some of which only work with Oracle, some only with MySQL, some with DB2, ...? Or, if Tim sees the usefulness of this function (to others, in the future), he can easily put it into the official DBI, and save hundreds of developers hours of time each?
Similarly in my own code - we put in a bunch of functionality that we won't use. But it allows our customers to plug in (using Java, C, perl, or even shell) and do things. We can't be sure that all of the functionality that we build in will be useful. In fact, I'm pretty sure that some of it is useless. Just that I'm not entirely sure which parts that is ;-) So we build it all, and hope they come. Er, we build it all and let each user decide which part(s), if any, they need. Maybe we'll use it, too, in the next version. But for now, we don't. Yet, as a public API which we think is large enough for everyone to do what they need to do, we have to build it now, even if parts of it will never be needed. If we waited to find out if someone needed a particular piece of function before writing it, well, our next release is slated for a year from the release of the current version. And, no, this cannot be fixed in between.
| [reply] |
