How can I get the function handle to the currently running function without relying upon the current path settings?

4 次查看（过去 30 天）
Michael
Michael 2013-4-17
编辑： Image Analyst 2014-10-7
The question says it all, but here it is again. How can I get the function handle to the currently running function without relying upon the current path settings?
function myFunction();
fxn = @myFunction;
doesn't work because myFunction is shadowed by a myFunction function which isn't the current function, so fxn is a handle to the wrong myFunction.
function myFunction();
fxn = str2func(mfilename());
fails for the same reason.
function myFunction();
fxn = str2func(mfilename('fullpath'));
is not a valid way to call str2func.
Any ideas?
P.S. - For the curious, I'm trying to run a unit test on a recursive function. To create mockup functions, I have a special path full of mockup functions which is added to the path after I get the function handle to the function which I'm testing. This allows functions within the function being tested to be replaced with mockups that simplify testing. However, this behavior with a recursive function actually prevents the test from being very useful.

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

采纳的回答

Andy Campbell
Andy Campbell 2014-10-7
One approach that you can take is to exploit the fact that the local functions have higher precedence than the functions that may be found on the path. Thus you should just be able to introduce one layer of function indirection in order to always dispatch to your recursive algorithm. So, instead of thi:
function out = myFunction(in)
stuff = doStuff;
out = myFunction(stuff);
end
It would look like this:
function out = myFunction(in)
out = myLocalFunction(in);
end
function out = myLocalFunction(in)
stuff = doStuff;
out = myLocalFunction(stuff);
end
This seems like it would work for you and be much cleaner and more efficient than path or current folder manipulation. However, I am confused because it seems like you want to dispatch always to the production myFunction so why is there a test double on the path at all? I guess I don't see why it is a problem because you don't seem to ever want to dispatch to the test double at all. Am I missing something?
  1 个评论
Michael
Michael 2014-10-7
编辑：Michael 2014-10-7
This was a long time ago, but I think what you've suggested would work.
To further explain, we have a lot of functions in our project, and each function has a associated unit test. We use the Matlab xUnit Test Framework. In order to provide mockup functions in our unit tests, our setup() method always looks like
function result = setup()
% Get function handle (in case mockup exists).
result.function = @myFunctionToBeTested;
% Add mockups to path.
result.previousMatlabPath = addpath(genpath('mockups'));
This allows the unit test on myFunctionToBeTested to have its subfunctions replaced with mockups. But when myFunctionToBeTested is recursive, it replaces the calls to itself with the mockup, defeating the purpose of its own unit tests.
We can't just not add the mockup path in a recursive function's unit test, as such recursive functions may depend upon other functions that we do want to replace with mockups. And creating separate paths to groups of mockup functions used solely by the unit test in question becomes unmanageable, practically speaking.
The solution I used works (see comment from me on April 23, 2013), but is obviously inefficient. I think, but have not tried, that using a local function for the recursion would do the trick. Thanks for that idea!
Good luck to others who are experiencing this same issue!

请先登录，再进行评论。

更多回答（2 个）

Roshin Kadanna Pally
Something to try:
You can determine this apriori and pass it as one of the input arguments to myFunction or save it in a mat file and load it back in your function.
fxn = @myFunction;
Execute above for the function you would be running beforehand. This need to be done only once and you can avoid shadowing by Cd-ing to the correct location.
function myFunction(fxn)
% fxn will always point to the currently running function
% Or, load a mat file that has fxn saved
  3 个评论
显示 1更早的评论
Michael
Michael 2013-4-23
I'm not sure exactly what you mean. I'm not trying to import a workspace, I'm just trying to call a function recursively. Outside of the unit test, this works just fine without using a function handle. But in the unit test, the path is altered, so the function name points first to a mock function, which does nothing. Therefore, I need to use a function handle to the original function.
In case others have this same problem, this can be made slightly more efficient by comparing the outputs of mfilename and which.
function myFunction()
thisFilePath = [mfilename('fullpath') '.m'];
if strcmp(thisFilePath, which('myFunction'))
fxn = @myFunction;
else
activeDir = cd();
cd(fileparts(thisFilePath));
fxn = @myFunction;
cd(activeDir);
end
% rest of the function would occur below including recursive call via function handle.

请先登录，再进行评论。

Image Analyst
Image Analyst 2014-10-7
Why can't you simply call dbstack() to get the currently running function?
  2 个评论
Michael
Michael 2014-10-7
This doesn't return anything more useful than I can get from the function mfilename (see my comment on April 23, 2013), and, as far as I can tell, doesn't help solve the original problem.
Image Analyst
Image Analyst 2014-10-7
编辑：Image Analyst 2014-10-7
mfilename is only the name of the m-file. dbstack gives the complete list of all the functions that have been called. So if main.m called fun1, which called fun2 which called fun3, dbstack would give you all of that (main->fun1->fun2->fun3) while mfilename could only give main.m. Though I don't think it's in the form of a "function handle."

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Programming 的更多信息

标签

产品

Community Treasure Hunt

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

Start Hunting!

Translated by