How can I get the function handle to the currently running function without relying upon the current path settings?
11 views (last 30 days)
Show older comments
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.
1 Comment
Daniel Shub
on 18 Apr 2013
Could you put the mockup functions in a package instead of adding the paths?
Accepted Answer
Andy Campbell
on 7 Oct 2014
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 Comment
More Answers (2)
Roshin Kadanna Pally
on 17 Apr 2013
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 Comments
Walter Roberson
on 18 Apr 2013
So you don't need the workspace of the current instantiation of the function?
Image Analyst
on 7 Oct 2014
Why can't you simply call dbstack() to get the currently running function?
2 Comments
Image Analyst
on 7 Oct 2014
Edited: Image Analyst
on 7 Oct 2014
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."
See Also
Categories
Find more on Matrix Indexing in Help Center and File Exchange
Products
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!