What are the downsides of passing function arguments as named values in a hash table/dictionary?

Question

I am building a multi-language API to query key value stores and I am debating (with myself) about whether to use fixed argument lists or dynamic argument lists using hash tables.

In general I do realise that static type checking is not possible when using hashes, but as long as there are unit tests this is not a problem. But are there any other disadvantages?

For instance, using arguments:

set(Key,Value)

:and using hashes:

set(key: Key, value: Value)

Update: I have since read this: There are some instances where keyword communication is inferior to positional. The most obvious is the call to a procedure that is defined having only a single parameter. The keyword is, of course, unnecessary. Generally, keywording without defaults will require more keystrokes; keywording with defaults will require less. For some of today's machines, the processing of keyword sequences will be somwhat more expensive than the processing of positional sequences. The most disturbing disadvantage may be that an unintantional omission of a parameter on the programmer's part might lead to a program executing incorrectly, but without noticeable errors, since the default value for the parameter would be used.

Answer 1

Using PHP, you'd have something like those for your function : first, using arguments :

function my_function($username, $password) {
    // Work with $username and $password
}

And using "hash values", you'd use an array :

function my_function($params) {
    // Work with $params['username'] and $params['password']
}

(And the idea is the same in other languages -- such as Javascript, for instance)

About hash values, a couple of great things :

• You can use any number of parameters
• You can pass them in any order you want

And at leat one very bad thing :

• You don't know what parameters you can pass !
  • Your IDE will not provide any help
  • You will not be able to extract that information from the code

About named parameters, a couple of great things :

• Better automated checks : if you don't pass an expected parameter, you can get a warning, both in your IDE or at compile/execution time
• Better documentation / hints in your IDE : type the name of the function, and you'll get the list of expected parameters and their (descriptive) names.

And for bad things :

• You have to pass the parameters in a strict order
• If you want to omit some parameters, you have to pass them a special value, like NULL.

Now, generally speaking :

• When I only have a couple of parameters, I use named parameters
  • It makes the function more clear : just look at its definition, and you know how to use it
• When I have more parameters, but almost all of them are mandatory, I generally use named parameters
• When I have many parameters, but most of them are optionnal, I generally use hash values.

Answer 2

Another problem with passing in a hash is typos on the key. In your function, you not only need to look for the parameters you were looking for in the hash, but you have to look for ones you didn't expect and complain, in case it's a typo. A bit of an extra burden.

But the strongest argument for me is that hashes of parameters don't allow compile-time parameter checking. I agree with Pascal that if you have a bunch of parameters, most of which are optional, it can be appropriate.

Answer 3

In general I do realise that static type checking is not possible when using hashes, but as long as there are unit tests this is not a problem.

This is a controversial opinion. Supporters of highly dynamic languages like Python tend to think this way, while supporters of static languages like C++/C# tend to disagree.

Having worked on both kinds of projects "in the wild", I can guarantee you that most Python projects don't have unit tests to cover even the basic function contracts, but EVERY C++/C# project has something that has the same effect - the compiler's checks.

Many would disagree, but I personally would not write this limitation off as "just write unit tests" - because most people don't.