Had a short discussion today with my programming colleagues about designing functions in an API to take positional parameters or named parameters. I think I can see pros and cons to both approaches, but I'd like to put them through the IGM and see what falls out.

We are coding an intranet application. There is a fairly powerful framework which has been developed along with the application (there is considerable intertwining, actually) and thus an API layer for both common things and database objects. The problem really began many months ago when some of the more versatile functions began to require more and more parameters to control their behaviour. Unfortunately, the language is PHP which natively supports only positional parameters, like most languages. Why is this a problem? Well, for many of these situations, the extra parameters are not used all that frequently and were often added to meet a need in a page. Calling such functions often results in needlessly specified parameters to get to the ones that really matter for this call.

I came up with a solution of a sorts when this began to be annoying. The solution was to pass named array parameters in a single argument that expects that. This works uniquely well in PHP because PHP does not distinguish between a list and a hash-table: PHP arrays always simultaneously function as both. There are now a number of functions that use this mechanism.

There are several advantages to this approach: the calling code is reasonably descriptive as to what it's passing to the function. Self-commenting, to an extent, and easier to maintain. It is also much easier to provide only the values that are non-default, without needing to re-specify essentially default values. The downside is that the function itself must be carefully commented as to what parameters it is looking for and what they do. A toolbox "setup default" function helps a little, as well as intializing defaults for unprovided parameters the options array. The other downside is that the calling code has no information about the omitted default parameters. So far the best way to combat that is to have obvious and sensible defaults (which can be harder than it sounds).

The traditional approach of purely positional parameters has the advantage of the function definition listing meaningful names (theroetically) for each parameter. However, the calling code becomes harder to read and understand. This is exacerbated when the first few parameters are clearly meaningful data, then there is a number of nulls, empty strings and zeros ending in an obviously unique parameter that provides few clues as to what it is for. This problem is particularly apparent when a number of the dozen parameters are merely flags, or some number of unknown units - this was one reason I went looking for something better, BTW.

Now, one of my colleagues said he doesn't like creating hash-tables on the fly merely for passing named parameters into functions, though he couldn't explain why this was a problem except in purely academic terms (e.g. "that's not what hashes are for"). His solution was to create more functions that exposed or assumed common combinations of available parameters. This, of course, creates more functions in the name-space, when adding options to an existing function often enables another virtually identical one to be removed (or not written) - this is the other reason I found a way to do named parameters. To be fair, he proposed wrapper functions, but I'm not keen on the namespace pollution. His reasoning for this solution was also along academic lines, but I might be mis-remembering his comments.

I know I tend to play fast-and-loose with so-called "right ways" to do things in programming. I've lost count of the things I've made PHP do that has startled a colleague (it's not that high a number, but I haven't been keeping count and looking back I wish I had).

Am I encountering someone who'd rather be a bit too safe? Or am I dicing with something a little too unconventional? What do people think about using PHP's arrays in this fashion? Is synthesizing named parameters worth the hassle, or should I go back to positional parameters?

Wade.

In fact, it's slightly worse. The string parsing required would be a significant drawback; in ease-of-use, in efficiency and in concept. FWIW, the PHP equivalent in my approach to that would be:
href('Forums', 'z.iwethey.org', array('underline' => false, 'target' => "_blank");

Wade.

This is not actually for your benefit, Bryce, but it looks to me that you just didn't get my point about how I've implemented named parameters. I'm not surprised, really.

Wade.

P.S. Oh yeah: don't take this the wrong way! :-) It's just that by this point in a conversation, experience has taught me that if you haven't gotten the original point, it's a waste of time trying to get you to see it.

And one we didn't think of! :-) Thanks.

Wade.