Undocumented features and future releases

I am considering making changes to the inputdlg command, and I understand this can be done by copying the function to my own library (together with setdefaultbutto n & getnicedialoglocatio n) and changing it there (I change the function name, so that the usual inputdlg can still be used). My concern is about future releases of MATLAB, that might change some internal stuff and make the function un-usable (while I will not be around to fix it), e.g. by changing soemthing in those accompanying functions I put in boldface, or the like.

I would appreciate your thoughts, especially if you have some past experience with release upgrades.

Answer 1

[Jan]

Programs are not stable or reliable, when the interpreter changes. For a trustworthy program any dependecies to undocumented functions of Matlab are forbidden, except if you force the customers to use a specific Matlab release. If this is not possible, and there are a lot of reasons to allow the usage of newer versions, automatic tests and fallbacks increase the stability.

In your case a short check (e.g. the very fast MEX-function FEX: isMatlabVer, which is more powerful and takes less time then Matlabs verLessThen) of the Matlab version can branch eitehr to your modified code, or to the standard inputdlg, when the used version is not contained in a list of tested versions.

Even documented features can change with the Matlab release, e.g. the order of elements in unique, setdiff etc., or the behavior of strncmp . Therefore exhaustive unit-tests and integrations-tests are required for a reliable program. Unfortunately it is not possible to test all assumptions about the built-in functions and there have been substantial changes in Matlab in the past. But a serious programmer can at least try to create an exhaustive test suite. By the way, such tests can reveal incompatibilities even for a Matlab version, which has been tested already: Some users might use modified versions of built-in function or re-coded functions of toolboxes, they do not own like nanmean etc.

[Josh]

Great answer, thanks. Upward compatibility can always be a problem, but the documented features at least get a warning to that effect in the new release documentation (or so I hope...). You helped me decide that changing the dialog is a bad idea at least in my situation, as I hate to think that on a later MATLAB version the system will fall back to the standard dialog (accepting the idea of checking for the version), making the users wonder what happened to the nicer dialog they were used to.

[Jan]

I've worked on a project for the assessment of surgical operations. While the reliablity of the results is the most important factor, the usage in the daily routine requires neat GUIs also. When this program is installed on a new computer, an exhaustive test suite is started, which runs for about 2 days. If a version of Matlab or the operating system is found, which has not been certified before, a warning appears and mentions all functions which call fallbacks. To keep this system flexible, the concerned M-files contain a line in the help section, which define the accepted Matlab versions. A tool searches the source code for these lines, such that an automatic message can be generated. These messages can be sent to the author to encourage him to certify the new Matlab version.

To support such platform independent programming, it would be very useful, if Matlab's documentation would contain a list of changes for each toolbox function. It is extremely hard to figure out, since which release fopen does not support the VAX format anymore. This is disappointing, because the quality of the documentation is extremely high actually.

Most of the changes in the toolbox functions are not documented in public. Only if the programmers think, that the users are affected, the changes are mentioned. This has not been the case for fopen in the VAX format or the reply of strncmp, when 0 characters are compared or more characters then the strings contain - to mention only 2 of the many examples.

[Josh]

I'm not sure my users will be thrilled with such procedures... Regression tests are bad enough even without undocumented features, especially since my users are not experienced, nor interested, in the technical aspects of the system; They are scientists, not IT people. I guess they will just have to do with them small fonts :-)

[dpb]

Jan pretty well covered the issues of making your own versions of TMW-supplied routines, I'll just make a general comment (if you search, you'll find this theme echo'ed in many of my comments for years here and on cs-sm :).

That is that if one is extremely concerned about long-term compatibility and stability, then Matlab (and similar proprietary languages) are probably not the toolset one wants to use for distributed code.

Being a proprietary commercial product, TMW controls the definition and features unilaterally and while they don't go out of their way to break things, they do so pretty routinely as they continue to move from the original procedural design to the object-oriented paradigm and introduce new features.

Unfortunately, part of what goes along with this paradigm is that the actual formal design specification/language "standard" is also proprietary and not published but only what documentation that is released is the defining word (actually not really "defining" either, the code itself is the end authority for behavior as far as the end user since there is no actual released specification).

Hence, any mission- or safety-critical application must go thru some similar verification process as Jan describes or require staying with a given release.

This is in marked contrast to the general languages such as Fortran, C, etc., which are defined by a published Standard that is a developed definitive tome as generated by the relevant standards committee. The advantage of the proprietary route is nimbleness and rapidity of implementation of new features and the prepackaged utilities and toolboxes; the disadvantage is the noted potential instability/change in behavior. The advantage of the Standard language is the ability to count on a compiler producing a known result (or at least knowing when a given construct is not "Standard usage" and the result is either "undefined" or "implementation-specific". The disadvantage, of course, is that changes to published Standards evolve very slowly in comparison so new features don't show up quickly and that there must be a reliance on either "roll your own" or outside libraries for the many things that come packaged with or are available as toolboxen from TMW.

So, again, it's a case where one has to weigh those relative advantages/disadvantages for a given application/purpose and decide which are the more important issues.

I've never tried to use Matlab or the like before the NRC for reactor-licensing purposes; I don't know what their specific requirements might be but I'd expect it to be onerous given the kinds of changes that can and do occur. It was serious enough effort to move from one compiler to another that one thought long and hard about it before doing so.

[Josh]

Thanks again. I pretty much agree with everything you said.