Is there a way to split MATLAB m scripts into a header file with multiple include files?

77 views (last 30 days)
So for a little background in regards to the point-of-view/perspective that I am coming into this question from -- I used to work in FEA/CAE and for large models, we used to have a master or header file that would have the run definition and some characteristics about the run and then we would have what we called "include files" that would contain the rest of the model information.
So, given that, what I am trying to do is something similiar with MATLAB m script files.
suppose that I have a MATLAB m script files that has 10 lines of code, let's call that test.m.
What I am looking to do is to split test.m (with lines 1-10) into two files, header.m (with lines 1-5) and include1.m (with lines 6-10) so that when I run the header, it would look like or appear to MATLAB as if it was just one giant file.
Note that the contents for include1.m isn't like a separate tool or function. It's just more information.
The way that we have it now is in one giant MATLAB m script file and I am looking to split it out so that if I want to have make changes, I can change the smaller include files rather going to line x in the much bigger file.
Is there a way to do something like that in MATLAB?
Thanks.
If there are any questions or any points of clarification needed, please let me know.
Thank you.

Accepted Answer

ES
ES on 5 Sep 2019
Hi,
since the original file (test.m) is a script, you can just split the file into as many segments (different files) as you want and call each one in order.
Make sure, when you split the files, you don't introduce any syntax error (like cutting in middle of an if or a for loop). That should be fine.
That is:
original file (test.m)
line 1...
line 10
New file 1(header.m)
line 1...
line 5
line 5.1 include1.m% here you are calling the second file
New file 2(include1.m)
line 6...
line 10
  3 Comments

Sign in to comment.

More Answers (1)

Steven Lord
Steven Lord on 5 Sep 2019
You can do what ES suggested and be okay some or most of the time, but this won't always work. Consider a function:
function y = function2
script1;
y = sin(alpha);
and the associated script named script1:
alpha = pi;
What happens when you try to call function2, expecting the output to be the sine of pi?
>> z = function2
Error using alpha
Too many output arguments.
Error in function2 (line 3)
y = sin(alpha);
You "poofed" a variable into function2's workspace at runtime, but when it was parsed MATLAB had already decided that the reference to alpha was a call to the alpha function since there was no indication in the function2 source code that alpha would be a variable at runtime. The alpha function doesn't return any outputs but MATLAB called it with one so it could pass that into the sin function. This type of approach has some of the same problems the eval function does.
If your "include" file's purpose is to perform some initialization (calling functions to configure your environment) without "poofing" variables into the workspace, it should probably be safe. To be extra careful, you could make it a function instead of a script so it does all of its work in its own workspace, isolated from the function that "includes" it.
If your "include" file's purpose is to define variables and/or data, I would make it a function that returns either the variables or a container (a struct, a cell, a containers.Map, a table, etc.) that stores the data. The file that includes it would then call it with an output argument. Compare a modified version of function2 named function3 (I'm just doing this for illustration purposes; you should use more descriptive names):
function y = function3
data = include3();
y = sin(data.alpha);
and the new include file:
function data = include3()
data.alpha = pi;
When you call this, you get the expected result.
>> y = function3
y =
1.2246e-16
This has an added benefit: if you decide to add something to the container returned by include3 (to support some other function that also needs to include it) you don't need to worry about breaking function3. Your function3 function doesn't need to care what fields other than alpha the struct data includes. If data.beta now exists too (to support a function4 that also "includes" include3) that's fine, even if function3 were to call the beta function.
Alternately if you have a lot of state information to keep track of writing a class object, using the constructor for the class or default property values to initialize those properties to their initial states, and having the class methods manipulate that state is a possibility. See the documentation for classes for more information.
  5 Comments

Sign in to comment.

Categories

Find more on Simulink Functions in Help Center and File Exchange

Products


Release

R2015a

Community Treasure Hunt

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

Start Hunting!