On my computers, this bit of code produces an error whose cause I have pinpointed,
load tstcase
ycp=lsqlin(I, y, Aineq, bineq);
Error using parseOptions
Too many output arguments.
Error in lsqlin (line 170)
[options, optimgetFlag] = parseOptions(options, 'lsqlin', defaultopt);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The reason for the error is seemingly because, in recent Matlab, lsqlin now depends on a utility function parseOptions, which is shadowed by one of my personal functions sharing the same name:
C:\Users\MWJ12\Documents\mwjtree\misc\parseOptions.m
C:\Program Files\MATLAB\R2024b\toolbox\shared\optimlib\parseOptions.m % Shadowed
The MathWorks-supplied version of parseOptions is undocumented, and so is seemingly not meant for use outside of MathWorks. Shouldn't it be standard MathWorks practice to put these utilities in a private\ folder where they cannot conflict with user-supplied functions of the same name?
It is going to be an enormous headache for me to now go and rename all calls to my version of parseOptions. It is a function I have been using for a long time and permeates my code.
3 Comments
Sign in to participate
Matt, I think you're seeing the results of decades of evolution in code organization and MATLAB language features, combined with a possible mistake with the apparently recent addition of parseOptions.
Private folders were introduced in MATLAB 5, 1997, and these helped begin to get utility / helper functions off the search path. However, private functions can only be called by functions in the directory just above them, and so they aren't helpful for sharing code between toolboxes. The toolbox/shared location was created for this purpose. It helped with toolbox code sharing, but the functions there were still on the main search path.
Namespaces, formerly called packages, weren't introduced officially to the MATLAB language until around 2008. Today, I think the best practice would be to put helper functions such as parseOptions into a namespace with ".internal." in the name. That way, the helper functions would not conflict with yours.
The function toolbox/shared/optimlib/parseOptions.m has a copyright line that starts with 2023, indicating that it was recently introduced. In my view, this was an architectural mistake. A helper function like this, with such a generic name, should not have been added to the main search path. It should have been placed in a namespace. You have good cause to complain.
There have been MATLAB language design discussions about features that would help avoid the shadowing problem that you ran into here. I don't know the current state of those efforts, and I wouldn't be able to discuss it even if I did. I will just say that I'm really hoping those design discussions turn into real features.