We may need to replace the function currently named `runtests` with a
completely different Matlab compatible function, which would break all
existing uses of `runtests`. How should we approach this?
A recent bug report  asks for a Matlab compatible `runtests`
function, presumably to provide a calling interface and to run unit
tests that are written in Matlab's test format.
As you may know, Octave already has its own `runtests` function, which
runs all Octave style unit tests in a directory. For example, several
Octave Forge packages use `runtests` in the maintainer makefile to run
Assuming the request is reasonable, these two uses of the same name are
incompatible, so we would probably want to retire the Octave `runtests`
function, or at least kill its name, sooner rather than later.
Separately, Andrew Janke has been working hard on a Testify package 
for Octave that seeks to improve on Octave's unit testing framework. The
`runtests` replacement offered in Testify is already a significant
improvement over Octave.
Questions for discussion:
Does Octave need to provide a Matlab compatible `runtests` function?
What other work would this new function require? Respond with EWONTFIX
and move on?
Probably. It is annoying when Octave has a good idea, that Matlab
then adopts, but for which they change the syntax to make it
incompatible, thus imposing a whole lot of unnecessary code
rewriting on existing programmers. In Microsoft's monopoly period
this was termed "embrace and extend". Of course, it's not just us
they inadvertently screw. They seem to inflict a lot of pain on
their existing user base by arbitrarily changing function names
pretty routinely. For example, the function 'bitmax' drifted and
Because there is no Language Reference Manual for the Matlab
language, The Mathworks' implementation itself defines the
language. Hence, if we are going to speak "Matlab" we need to
accept their definition of what words mean.
Whether that is done or not, should we avoid the name `runtests` in
Octave anyway to head off any potential future confusion? Or to allow a
package to attempt to implement it without shadowing problems?
There is already a historical example of this happening with the
strsplit function. Matlab introduced a function of the same name
with different syntax. We followed suit and developed a compatible
strsplit function. But, Octave's original function was 4X faster
and it seemed unwarranted to throw a good function away. Instead,
we prepended the letter 'o' for Octave to create 'ostrsplit' which
is still in the strings/ function directory and still used
throughout the scripts directory.
If we do want to include this function, maybe not now but someday,
should we do anything in the near term for Octave 6?
At the moment, my preference would be to deprecate the `runtests`
function we have now in Octave 6, and point users to the Testify package
for improved replacement test functions.
Is there a compelling reason to keep `runtests` in Octave, possibly
under a new name?
Yes, in my view we need to make changes gradually so that
programmers have time to adapt their code. The simplest way to do
that would be to create an 'oruntests' function which preserves
existing functionality. Starting deprecation in Octave 6 seems
fine, but the warning message should indicate that oruntests
exists for an exact replacement, and that the Testify package
exists with extended functionality.