How to pass the whole workspace to the function? Not so fast.. I have requirements.

19 views (last 30 days)
I know, you don't want me to and you don't see a reason why. You will tell me to pass arguments directly to a function, because it is the most secure way. I do it. The life could be so much simpler if I could pass a workspace. I have requirements. Let me explain. I have a style, though you may call crazy if you want.
When I work on some project I usually have only two files. The first file is a library of all the functions for the project. It is actually a class, with functions attached to it. Here is the example:
function class = ProjectFunctions()
class.Square = @Square; % Return a square
class.VectorM = @VectorM; % Return a sum
end
function ans = Square( q )
q^2;
end
function ans = VectorM( q, a)
q+a;
end
Why do I do it? Because as the number of functions grows, my head explodes, if I keep all the functions in different files and I need to keep opening them and jumping between tabs and I can't remember who is called what... What I mean it's crucial for my calm workflow to have this library in the single file. It has a header, where I can see all my functions and their explanation. With the help of Ctr-F I can quickly jump to the function itself. Ugly or not, it's the best way I have found to have many functions in one file, that you need to address independently.
The other file I have is the main script that I run. It's short as possible. It tosses functions from the class like this.
f = ProjectFunctions();
q = 2;
qSquare = f.Square(q);
This script is more like a plan, like an overview of what is actually happening. It is also the playground for the future functions. It has a dirty part that I am working on, but when it is debugged, clean and clear it's packaged into a neat function and transported to the library.
It is VERY convenient. It gives me the big picture and quick access to details at the same time.
But here where the problem comes. Some main important functions need many many variables from my workspace. Not 600 like here, but like 20. And my naming conventions are opposite of usual Matlab all lowercase truncated and in comprehensive ones.
So how do I just pass my entire workspace to the function and maintain the beauty of my organisation at the same time?
To eliminate possible solutions.
  1. Marking all variables global is tedious, as I have to assign them global both in the function and in the script and keep track of which are added and which not.
  2. Persistent variables won't help.
  3. Having scripts instead functions will help. But I can't have many scripts in one library file.
  4. Couldn't make it work with evalin, assignin, but maybe I am missing something.
  5. Having all workspace variables in a big structure would require constant addition of a prefix and will hinder the observability of the variables. Will it also be slower?

Answers (1)

Walter Roberson
Walter Roberson on 11 Jan 2014
The "main important functions": which of the two files are they in? And which workspace are the variables in, considering that each function has its own workspace?
When the functions graduate to the library, is the way they access variables altered, or is everything calling on a "pool" of variables that are held in common?
If you have a pool of variables in common, you should consider class variables, which become like "shared variables" within your methods.
If your naming system does not have a clear distinction between variables that are local to methods and those that are in the desired shared workspace, then you are likely to encounter the same sort of conflicts that you get with global variables.
  2 Comments
Dougal
Dougal on 11 Jan 2014
The functions are in the library file. The variables are in the script file workspace and usually I just pass a couple to a function.
I haven't considered class variables. Do I have to access them via this.variable?
Walter Roberson
Walter Roberson on 11 Jan 2014
I do not know enough about MATLAB classes to know the syntax for class variables.
There is no "script file workspace". Scripts run in the workspace of the function that was used to invoke them. If they trace all the way back to the command line without a function being involved then they operate on the "base" workspace, which is the same workspace accessible through evalin('base') and assignin('base')

Sign in to comment.

Categories

Find more on Debugging and Analysis in Help Center and File Exchange

Community Treasure Hunt

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

Start Hunting!