Why does not overloading using assignin work?

Hi, I have noticed something strange. It have most likely to do with the fundamental structure of matlab. What I wonder is if there are some known (and expected?) problems with overloading functions with assignin. What I want to do is to create a variable called colorbar. This must then overload the function colorbar.

To avoid all comments: I know that it is normally bad practice to do like this, but I am afraid that the change would be is more or less out of my hands.

To show the problem I have provided 2 examples. The first one works fine:

function testFcn()

colorbar = 'none';
disp(colorbar)

The output is none as I want. The second example does not give the expected output:

function testFcn()

assignFcn();
disp(colorbar);
return; % Dummy line, set breakpoint here

function assignFcn()

myVar = 'colorbar';
assignin('caller', myVar, 'none');

the output is an axes handle here. However, if a breakpoint is set at the same line as return (or on the same line as disp as well) and disp(colorbar) is executed in the command window I will once again get the expected output.

This can of course be solved by assigning a value like colorbar = 'none', but what I am interested in knowing is why it does not work with assignin. Is it a bug or is this the expected output?

EDIT:

After some thinking I think that I have found the reason. The guess is that while assignin is evaluated in runtime the decisions whether something is a variable, a function, not defined,... is done by the compiler, there can be a problems here. The compiler will then treat colorbar as a function since it cannot see what will happen inside assignin. If someone want to use assignin to assign a value to a variable, then eval or evalin is required to evaluate the variable as well.

Does this make sense?

[Matt J]

Yep. It's a well-known hazard of assignin, evalin, load, etc..., which is one reason why creating variables inexplicitly with them is often discouraged. Why can't you just return 'colorbar' as an output argument from assignFcn?

[Patrik Ek]

It is of course true and it is also possible to assign a default value. However, the function submitted is a variant of a function that sets the variable if it does not exist. I could of course do it in many other ways and also ways not including assignin (for example if statement if ~ exist set variable). I could also set a default value of colorbar in the function where I am since I use varargin anyway. However, since I was not the creator of the function and since the function is widley used where I work I chose to use it. However, when I noticed this problem and also found out that I only got problems for overloaded variables, I got curious.

Answer 1

[AJ von Alt]

Patrik,

The MATLAB Answers article Why do I receive an error when I load an array with variable name 'i' and query its value i(1) in MATLAB 7.3 (R2006b)? expains what is happening.

When testFcn is run colorbar is visible as a function and is there for bound to the function. Evalin will not bring the variable colorbar into scope until after testFcn has begun to execute.

One way to workaround this behavior is to let MATLAB know that you intend to overload colorbar in the testFcn scope by initializing it at the start of the function.

function TestFcn()
    colorbar = [];
    assignFcn();
    disp(colorbar);
    return; % Dummy line, set breakpoint here
function assignFcn()
    myVar = 'colorbar';
    assignin('caller', myVar, 'none');

[Patrik Ek]

I am afraid that is hard since the code snippet is a part of a function that tests if a variable exist and if not defines it. In that perspect assignin is justified. However, the answer, answers the question. I can find workarounds so it is really not a big deal. However, this is something that is good to learn. Until I tried to overload a function there was really no issues, so it is good to learn what may be potentially dangerous. Thanks

Answer 2

[per isakson]

There is a function

    why

to explain behaviors like this one. I use it when help doesn't help.

I added whos before disp(colorbar) in testFcn, which confirms that assignFcn works as expected.

Yes, your EDIT make sense. (I tried feature('accel','off') and feature('jit','off'), which however didn't change the behavior.)

The MathWorks Support Team (see link by AJ von Alt) writes "This is expected behavior." &nbsp However, as far as I can find it is not documented behavior.

IMO: Matlab should at least issue a warning.

[Matt J]

IMO: Matlab should at least issue a warning.

I don't think MATLAB can anticipate when it is going to happen. It would have to analyze the content of the input strings to assignin. If it could do that, the problem probably wouldn't exist at all.

[per isakson]

I'm a naive user of a high level language.