One Function Per MEX Compilation Unit
The One Function Per M-File rule gets especially frustrating when extended to MEX, MATLAB's system for writing native code that exposes itself to interpreted MATLAB code. MEX wraps one of several C or Fortran compilers and compiles your code to a shared library called a MEX file. Each MEX file then can only expose exactly one name to the MATLAB interpreter.
Want two functions to be exposed? They must be in separate compilation units, and thus may not directly share state. This restriction makes it easier for the MATLAB interpreter to find your symbols by reducing the problem of resolving an unknown function name to that of finding a file with a given extension, but makes it very difficult to write code that shares resources in a sensible way.
On Stack Overflow, it has been suggested that accepting an additional string, then writing several public M-files to pass that string, is a good way of working around this problem. This workaround makes code organization more opaque, however, and causes the programmer to have to define each function to be exposed via MEX multiple times.
