Why does not overloading using assignin work?

2014 8 25
2 个回答
回答已采纳
更新时间：2014 8 25
10 次查看（30 天）

0 个投票

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?

2 个评论
显示 无 隐藏 无

Matt J
Matt J 2014-8-25
编辑：Matt J 2014-8-25
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
Patrik Ek 2014-8-25
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.

请先登录，再进行评论。

请先登录，再回答此问题。

 采纳的回答

AJ von Alt
AJ von Alt 2014-8-25

1 个投票

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');

1 个评论
显示 -1更早的评论 隐藏 -1更早的评论

Patrik Ek
Patrik Ek 2014-8-25
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

请先登录，再进行评论。

更多回答（1 个）

per isakson
per isakson 2014-8-25
编辑：per isakson 2014-8-25

1 个投票

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.

2 个评论
显示 无 隐藏 无

Matt J
Matt J 2014-8-25
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
per isakson 2014-8-25
编辑：per isakson 2014-8-25
I'm a naive user of a high level language.

请先登录，再进行评论。

类别

在 帮助中心 和 File Exchange 中查找有关 Whos 的更多信息

标签

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by