I am constantly frustrated when designing APIs in JavaScript that lend themselves naturally to the kind of overloading you can do in languages like Java or C#. The options are:

1. Write several functions with slightly different names to deal with all the possibilities. Pros: clean to implement. Cons: bloats the API, hard to use.

2. One function with overloading. Pros: quite simple to use. Cons: still requires remembering/looking up combinations of arguments that may be passed, and requires code in the implementation to check number and types of the arguments.

3. One function that accepts a single object whose properties are just the arguments the caller requires. Pros: easy to use, flexible. Cons: requires extra code in the implementation to check properties of the object passed in, introduces possibility of error by mistyping property names in the calling code.

I was stating a preference in response to your comment “overloading can lead to code that performs brittle type checks.”

I certainly didn’t mean to imply setter/getter pairs require more parameters than accessor methods.

Ash

Obviously a lot of this is down to personal taste, and I have vacillated about overloading myself, coming down mostly on the side of avoiding it, though not religiously. I’m probably being thick but I think I’m missing your point – why would having separate setCookie and getCookie functions mean needing to supply more parameters?

Tim