We are at a point where we need to greatly improve the flexibility of runDMFT and postDMFT packages. Spanning only Uloc values in all the computed and analyzed lines is becoming too limiting. I want to be able to span whatever variable I want (passing its fortran name) and keep Uloc just the default. Yet I don't want to drop other optional arguments and the positional nature of default Matlab arguments makes all this a nightmare. Finally I'd very very much prefer to not break the API, as I want my old scripts (scattered around in Ulysses and elsewhere) to keep running, if I ever need to (I have to admit this might be hard, we'll see...)
So inputParser objects might be the way to go. They are not particularly new in the language (since R2007a), but for some reason I never heard of them before, so there might be some pain points. I need to find time to investigate about them.
https://it.mathworks.com/help/matlab/matlab_prog/parse-function-inputs.html
https://it.mathworks.com/help/matlab/ref/inputparser.html
https://it.mathworks.com/help/matlab/matlab_prog/input-parser-validation-functions.html
We are at a point where we need to greatly improve the flexibility of runDMFT and postDMFT packages. Spanning only Uloc values in all the computed and analyzed lines is becoming too limiting. I want to be able to span whatever variable I want (passing its fortran name) and keep Uloc just the default. Yet I don't want to drop other optional arguments and the positional nature of default Matlab arguments makes all this a nightmare. Finally I'd very very much prefer to not break the API, as I want my old scripts (scattered around in Ulysses and elsewhere) to keep running, if I ever need to (I have to admit this might be hard, we'll see...)
So
inputParserobjects might be the way to go. They are not particularly new in the language (since R2007a), but for some reason I never heard of them before, so there might be some pain points. I need to find time to investigate about them.