Process named Arguments

Easily add optional, named arguments to your functions, like this: f('var_name', value).

Description

Assigns named arguments passed to your function (as in plot(), etc.) to local variables. The name of the argument is the name of the local variable in your function.

 Example: inputfun('prompt', '>', 'defval', 5.1, 'timeout', 5);

Really simple and easy to use; other implementations of this idea on File Exchange require a lot of overhead to set this up, where as my code just requires one extra function call near the top of your function.

 Usage:
(1) in your function, define vars with default values;
(2) call procArgs(varargin)

 Minimal error checking: requires that all passed variable names match already defined variables in your function. It would be pretty easy to add type checking if you wanted it (I don't, particularly).

Example:

 %% example function using procargs
function test(varargin)
 name = 'John';
 age = 32;
 procArgs(varargin)
 fprintf('name=%s, age=%i\n', name, age);
 
 %% example calls
 test('name', 'Amber'); % prints Amber, 32
 test('age', 99); % prints John, 99
 test('Ages', 0); % error, will report that Ages is not defined.

• MATLAB release: MATLAB 7.4 (R2007a)

[Jan Simon]

In my opinion, this will handicap the debugging drastically, because it hides the source of values.

Checking the existence of a variable with "exist('Name')" is slow and fails if a matching file, folder, class name or built-in function exists. Safer and faster: "exist('Name', 'var')". At least it is a good idea to include this test: Allow JIT compilation, avoid collisions between variables and built-in functions (can appear even for different upper/lower-case).

[Alan Robinson]

Thanks Jan, I've made the change to exist that you suggest. Are you saying that this change would effect whether the JIT could compile this function or not? I would think the use of Eval would pretty much prevent that. Unless you are using a lot of named arguments inside an inner loop, however,I don't think the speed of procArgs is going to influence much. Calling it 10k times with two named arguments takes 5s on a 2.6Ghz P4 (Matlab 7.3). Nonetheless if you have suggestions on how to speed it up I'm interested in hearing them.

 I don't really see how this causes a problem with debugging though - you can always check the contents of varargin if you need to know what values were passed in.

[Jan Simon]

If the EXIST test would be omitted, procArgs could even *create* variables in the caller. But this would be dangerous and would confuse the JIT compiler: "assignin('caller', 'RANK', 1)" collides with the Matlab toolbox function 'rank' (at least in Matlab 6.5 and 7.7). Therefore I appreciate that you've included (and updated) the EXIST test.
You are right: debugging is not impossible. ASSIGNIN and EVALIN can obfuscate a program and predicting the effects can be really hard. But to be honest: one can write obfuscated source even without ASSIGNIN! procArgs with some good comments can be much better than a hard coding without comments.
Rating: H1 line, help, example, version number, name of author: exsiting. Function works, is useful and usable. I personally prefer hardcoded access of variables and this might be a question of taste.