MATLAB: A way to work around MATLAB’s inability of put a local function into M-script

MATLAB

I have been wondering why we are not allowed to put a local function in a script file. According to related threads below, it seems that I am not the only one.
http://www.mathworks.com/matlabcentral/newsreader/view_thread/298837
https://www.mathworks.com/matlabcentral/answers/7685-m-function-in-a-m-script
Down side of creating functions that are only to be used for a specific script might be…
  1. Names: If you keep doing this, your folder will be cluttered with lots of one-shot functions, and it is highly likely that you end up having lots of them with very similar and confusing names. Once you loose the track of record, you might not able to work out which function is right for you.
  2. Scope: Closely related to the above. Functions that are put in a folder are within the scope of all other files in the folder, or if the folder is in the MATLAB search path, of all the MATLAB files. Frequently used utility functions and those one-shot functions will be mixed up. Finding a right function may become more difficult with lots of other candidates with confusing names. Ideally, your one-shot functions should be only visible to the script that they were dedicated to.
  3. Maintenance: If you have to prepare five separate function .m files for one script, it would be more prone to loose their integrity, when copied to other place or people, for example. One-shot functions should better be kept in one place for maintenance.
I've been thinking about this, and came up with a very basic approach that can work around most of the above issues, albeit not entirely.
1. Use date-based sequential stem name for script file. A name like "scr2016_07_05_200000_xxxxx.m" may be beneficial, in that all the script and related files (html, mlx, pdf) will be shown in date order. It is easy to relate these sibling files. Also, it is useful to remember what you were up to on a specific day. Sequential numbering is a great way to avoid the pain of thinking of a unique name for just simple scripts.
2. Deploy a utility class with static methods. Create a classdef file with the name "scr2016_07_05_200000_xxxxx_util.m" Leave properties empty and put an attribute (Static) to methods as below. And then, you can add as many static functions as you want here.
    classdef scr2016_07_05_200000_xxxxx_util
        %scr2016_07_05_200000_xxxxx_util
        properties
        end
        methods (Static)
            function out1 = func1(var1, var2)
            end
            function out2 = func2(var3, varargin)
            end
        end
    end
3. In your script, call an instance of "scr2016_07_05_200000_xxxxx_util" as below (Note you don't have to create an object to use Static methods. classname.staticMethodName(args,…) works. Below is just to avoid repeating lengthy class names.):
u = scr2016_07_05_200000_xxxxx_util;
4. Then, you can access to the static functions like this.
C = u.func1(A,B)
Benefit of this approach so far may be…
  1. Scope of those static methods are limited.
  2. You can find all of the related function in one place.
  3. You don't have to worry about thinking of absolutely unique function names every time. You only have to worry about uniqueness within the class, which is pretty easy.
  4. In essence, your script will have a twin brother of a dedicated utility class. I found that working on a .m or .mlx script and the classdef .m file side by side in one screen was extremely efficient. Your script will show abstract code on the left, and detailed workings in static methods in the classdef file on the right.
I'd like to hear your even better ideas or constructive feedback.
Thank you for reading.
Best, Kouichi

Best Answer

Hi,
how about giving 16b a shot? Just do it ;)
Related Question