问题
I'm trying to turn some code written in Matlab into a standalone, compiled Matlab application. However, after getting some odd errors, I realized that the code makes a lot of use of adding and removing from the path to get around the fact that there are several functions with the same name (but different results/calculations) used multiple times. Looking around, I discovered that you can turn a folder into a package by putting a "+" in front of its name, and going through and making sure the functions in that package refer to each other using name_of_folder.name_of_function
. This solves the namespace problem, but it potentially creates a lot of work, in that I now have to go through and prepend the correct package to each function call (and I may still end up having to duplicate a lot of files).
Then I saw the import
function, and I'm hoping that'll save me some time. I think I can pass the package I want to one or two particular functions, have those function import the package, and then things will work the way I want--if the functions that those functions call fall into the scope of that import statement. E.g, if I set something up like
function foo(var1, var2, ..., packagename)
eval(sprintf('import %s.*', packagename));
...
bar1(var1, var2);
...
bar2(var2);
...
then I'm hoping bar1
and bar2
will use the package imported with the import statement. The documentation says that import statements in conditionals and functions are limited to that block of code, but I don't know if "that block of code" means that text only, or "that block of code" being the code and everything that evaluates as a result. I have a feeling it's the former, but I figured I'd ask in the hopes that it is the latter.
So, what is the scope of an import statement? Alternatively, is there another way to deal with this problem?
回答1:
The best approach for you is likely to take the pain of renaming until the "multiple functions with same name" problem is gone. It will make the code much easier for both you and future maintainers to understand.
Two options that are different than your package idea (which I like):
You can just append (or prepend) the directory name to the function name and put them all into a new (better-named) directory. Might make more sense, depending on the situation.
If you have two functions
foo
defined in directoriesbar
andcar
, and both functions take the same arguments, you can unify them in a single function that takesbar
orcar
as an additional argument:function foo(parm1, parm2, parm3, version) if strcmp(version, 'bar') // bar code else // car code end
This isn't great, but it's much better than munging the path, and it sort-of follows a MATLAB pattern (passing in a string argument to change the detailed behavior of the function). Even if the two
foo
functions have different arguments you can make this work, but you'll have to do annoying parsing of the arguments, at which point your packing idea looks much easier to me.
回答2:
I wrote some test code to try it out for myself, and indeed, the import statement is limited to only the function that called it, which makes sense but I guess my hope clouded my judgement. For the record, I wrote the following short functions to test it:
function package_test(package_name)
eval(sprintf('import %s.*;', package_name));
test_function();
end
function test_function()
nested_function()
end
and then put
function nested_function()
disp('I\'m in the original folder :(');
end
in the same folder as the first two functions, and
function nested_function()
disp('I\'m in the package! :)');
end
in a folder named +trial
. Of course, when I ran package_test('trial')
, I saw "I'm in the original folder :(" displayed in the window, while trial.nested_function()
gave me the string I hoped to see.
Furthermore, the eval
function poses a problem to the compiler, and replacing it with import(sprintf('%s.*', package_name));
doesn't seem to help either. So it looks like I'm back to duplicating files.
来源:https://stackoverflow.com/questions/13076365/what-is-the-scope-of-matlabs-import-function