Is there a simple way to convert all fields of a struct to local variables?

I have a matlab program with a lot of variables (boolean, arrays, doubles, logicals, strings), to the point where it becomes unwieldy to alter the workflow. I often don't know which I'm going to need when I add new functionality.

So if I create a function with a series of recursive function calls and X layers deep I discover I need a variable I didn't feed into it, I need to add those variables in the right order as arguments to every function in the recursion. This seems both risky and tedious. It also makes for messy code as functions get passed 20+ arguments.

So I created a struct "programConstants" at the beginning of the program flow that aggregates all of the variables inside of it. So I can access them like:

programConstants.someThing;

Is there a simple way I can just dump all of the programConstants fields into the scope of a function when I pass it?

I would like to avoid accessing the variables from the struct. For example, if I want "someThing", I'd like to just be able to write:

someThing;

instead of:

programConstants.someThing;

[Rik]

You could add a parser function, or use deal. I strongly discourage you to loop over the field names and use eval to poof the variables into existence.

[dpb]

I'd suggest just shorten the struct name into the function...there's virtually no difference in typing between

pc.someThing

and just

something

and you have variable completion from the struct that can help, besides.

I understand if the stuct name is

bigAndLongAndUnwieldy.SomeOther_RidiculousNameStringThatFollows

I really dislike the direction TMW is taking in some of their newer stuff along those lines, myself.

ADDENDUM

Reading a couple others and re-reading the original Q? I think I misinterpreted somewhat. I still agree with my previous comment but I missed the idea of passing all the variables themselves; I was just presuming you were passing the struct.

That's the key, pass the struct and the structure only to the function; then it doesn't matter to the function what you do to it; unless you completely remove one or change its name internally or somesuch. Adding or removing any not used in a given function is totally transparent and nothing is required to be change if you do make changes that don't affect that particular function.

If there are various categories, and some that are only need for a given portion of the application, you could consider some segregation and consolidation along those lines.

Since ML only does "copy on demand" there's no memory penalty in the structure being in the argument list.

[Stephen23]

"This seems both risky and tedious."

It is.

"So I created a struct "programConstants" at the beginning of the program flow that aggregates all of the variables inside of it"

Good idea. That is the recommended approach to passing lots of parameters.

"Is there a simple way I can just dump all of the programConstants fields into the scope of a function when I pass it?"

Not really.

There are ways, but they are not recommended, because magically making variables appear in a workspace is how beginners force themselves into writing slow, buggy, complex code. Read this to know more:

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

"I would like to avoid accessing the variables from the struct. For example, if I want "someThing", I'd like to just be able to write: someThing instead of: programConstants.someThing"

Just shorten the name, e.g. S, then you just need to call this:

S.someThing

I don't see any point in inefficiently duplicating in memory what can already be accessed simply from that structure. Accessing the structure is what experienced MATLAB users would do.

[Doug Rank]

I'm trying to avoid this approach as there is a lot of code (~100 files) that would need to be updated to accommodate the ~50 possible parameters. Not all of the functions get passed an unwieldy amount of parameters, but I figured consistency would be best.

[Rik]

Changing the structure of a project/code can be a big time-investment, but it may save you a lot of time in the future.

[Stephen23]

"I'm trying to avoid this approach as there is a lot of code (~100 files) that would need to be updated to accommodate the ~50 possible parameters."

This is a one time cost, which will be worth the investment. The advanced Find Files tool, or a good text editor could probably help you.

Do this properly once, rather than writing hack code to magically make variables appear all over the place (which will ultimately just cost you more time debugging and consume memory and slow your code).

Using one structure will save on memory usage: simply pass that structure to all 100 functions, and MATLAB will not actually copy the data in memory (as long as the data does not change): all 100 functions can happily use one instance of that structure in memory. In contrast when you magically create those variables in each workspace, you just pointlessly duplicate all of the variables 100 times. So not only will it slow your code down and make it buggier, it will pointlessly waste memory.

"Not all of the functions get passed an unwieldy amount of parameters, but I figured consistency would be best."

Probably. Do it once, do it right.

[dpb]

Amplifying on the above, with the structure you don't have to do every function at once; all you must do is begin with the one(s) you're working on actively at the moment and change their interface and add the structure name prefix to the variable(s) being used internal to the function (you did keep those consistent, right?). Everything else can remain as is with the variables existing as separate; you simply have to update the structure as well if it contains results as well as inputs.

This is a less than ideal implementation but will let you make the transition over time rather than requiring a complete refactoring all at once.

But I'd reiterate the others--it'll pay large dividends in the long run if this application has any future life expectancy as sounds as does...

Answer 1

[Steven Lord]

I have a matlab program with a lot of variables (boolean, arrays, doubles, logicals, strings), to the point where it becomes unwieldy to alter the workflow. I often don't know which I'm going to need when I add new functionality.

That does sound problematic. The risk of breaking such tightly coupled code is high if you're not very careful.

So if I create a function with a series of recursive function calls and X layers deep I discover I need a variable I didn't feed into it, I need to add those variables in the right order as arguments to every function in the recursion. This seems both risky and tedious. It also makes for messy code as functions get passed 20+ arguments.

I agree with your assessment about the risk, mess, and tediousness.

This isn't directly related to your main question, but one way to reduce some of the risk associated with modifying or refactoring your functions would be to write tests for your functions that can reduce the chance that you'll accidentally change the behavior that some other function depends upon when you update your function. This could also help you if you want to refactor your code to make it easier to understand and extend in the future: extract a small segment of functionality into its own function, unit test it thoroughly, and add an integration or system test for the function(s) that call it.

So I created a struct "programConstants" at the beginning of the program flow that aggregates all of the variables inside of it.

IMO that's a step in the right direction, but you have everything crammed into one struct array. Are there logical groupings of the information that your functions need where you could create multiple struct arrays or perhaps even separate classes? So instead of having programConstants you could have carParameters, personParameters, etc.?

Is there a simple way I can just dump all of the programConstants fields into the scope of a function when I pass it?

There are ways to do what you ask, but I recommend against it. If one of the fields in your programConstants struct matches the name of a MATLAB function (commonly-matched functions include alpha, sum, min, max, etc.) then depending on what you do in your function MATLAB may call the function rather than referring to the variable that was "poofed" like a magician's rabbit into the workspace at run-time.

If you're only going to use a particular piece of data from the struct once in your code, consider just accessing it from the struct. If you know you're going to use a particular piece multiple times, then it may be time to define a local variable. But I would limit this to just what your function is going to use. This would be more work than simply dumping everything from the struct into the workspace, but it would also be less likely to cause the "poofing" confusion I described in the previous paragraph.

[Doug Rank]

Are there logical groupings of the information that your functions need where you could create multiple struct arrays or perhaps even separate classes? So instead of having programConstants you could have carParameters, personParameters, etc.?

Yes I think this is going to be the best way to handle the situation as there are logical groupings.

This will make the code clearer too, as the code takes advantage of a lot of array operations (it is matlab after all) and having "pc." everywhere is just going to make my eyes bleed. At least if I see "bird." I'll know it's a "bird" property coming from something with length number-of-birds (or whatever this program might be looking at).

We have started writing tests a few months back, but there is a lot of legacy code without tests. And unfortunately - writing tests then refactoring the arguments means you have to refactor the tests too. It's a bit of a catch-22 for minimizing the technical debt load.

I think I will follow this going forward and refactor older code whenever changes need to be made or there is slack time.

[dpb]

Very cogent and concise summary of all comments, Steven! Kudos...

[Steven Lord]

We have started writing tests a few months back, but there is a lot of legacy code without tests. And unfortunately - writing tests then refactoring the arguments means you have to refactor the tests too.

It can be painful, I agree. But it sounds like you're approaching this from the top down, starting your refactoring with the whole application. While that seems like the obvious starting point (begin at the beginning) that's also the most daunting approach IMO.

Instead consider isolating the commonly used lowest level pieces first. Decide what single responsibility each of those small pieces should have (splitting those small pieces that are trying to do too much), lock down their interface, unit test them, and then hopefully you never have to touch those functions (or their tests) again.

You will need to change the callers of those functions to react to any interface change, but you would have had to do that anyway. And this way you only need to keep a small chunk of the overall system in your mental cache at once.

[Stephen23]

@Doug Rank: for a project of that size and complexity you need to be using best practice, such as using and following the advice of the static code checking tools to ensure that every function does not have any warnings or obvious bottlenecks. This then requires you to not magically make variables appear in any workspaces, because static code checking tools don't work with variables that magically appear at run time!

Best practice would also include using a good versioning system, e.g. GIT. This will make updating and keeping track of the versions much simpler.

Answer 2

[OCDER]

Look into inputParser and the StructExpand option. https://www.mathworks.com/help/matlab/ref/inputparser.html

% S = struct('Var1', 1, 'Var2', 2, 'Var3', 3, 'Var4', 4);
% testFcn(S)

function A = testFcn(varargin)
P = inputParser;
P.StructExpand = true;
P.KeepUnmatched = true;
addParameter(P, 'Var1', 0, @isnumeric);
addParameter(P, 'Var2', 0, @isnumeric);
addParameter(P, 'Var3', 0, @isnumeric);
%addParameter(P, 'Var4', 0, @isnumeric); %This function happens to not need Var4, for example.
parse(P, varargin{:});
P = P.Results;
P %show the output

Or you could just pass the structure itself.

function A = testFcn(S)
if ~isfield(S, 'Var1'); S.Var1 = 1; end
..

Answer 3

[Pouya]

Yoiu can use fieldnames function in conjuctions with assignin

The assignin function is handy for this task, as it allows you to assign values to variables in either the base workspace or the current function/workspace.

% Get a list of all field names in the structure
fieldNames = fieldnames(programConstants);

% Loop over each field name and assign its corresponding value in 'data'
% to a variable with the same name in the base workspace
for i = 1:length(fieldNames)
    fieldName = fieldNames{i};
    fieldValue = data.(fieldName);
    
    % Assign the field value to a variable with the same name in the base workspace
    assignin('base', fieldName, fieldValue);
end

Alternatively you can wrap the same code into a handy function and use 'caller' instead of 'base'. :

function structToVariablesCaller(inputStruct)
    fieldNames = fieldnames(inputStruct);
    for i = 1:length(fieldNames)
        fieldName = fieldNames{i};
        fieldValue = inputStruct.(fieldName);
        assignin('caller', fieldName, fieldValue);
    end
end

[Rik]

As explained elsewhere in this thread, this method of creating variables out of thin air is not a good idea. It is a lot harder to track variables this way, making debugging needlessly difficult.

It sounds like you think 'base' is the current workspace. If so: that is incorrect. Each function has its own workspace, so if you use the first suggestion inside a function, it will not work.

And a final note: you should use numel or size. There is hardly ever a reason to use length, and this is no exception.

[Stephen23]

"The assignin function is handy for this task"

The ASSIGNIN function results in slow, complex, inefficient, obfuscated code and makes debugging harder:

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

See also Steven Lord's answer: https://www.mathworks.com/matlabcentral/answers/414885-is-there-a-simple-way-to-convert-all-fields-of-a-struct-to-local-variables#answer_332854