octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: runtests function


From: Rik
Subject: Re: runtests function
Date: Fri, 17 May 2019 17:15:03 -0700

On 05/17/2019 04:24 PM, address@hidden wrote:
Subject:
runtests - keep, rename, or delete?
From:
Mike Miller <address@hidden>
Date:
05/17/2019 12:48 PM
To:
address@hidden
List-Post:
<mailto:address@hidden>
Precedence:
list
MIME-Version:
1.0
Message-ID:
<address@hidden>
Content-Type:
multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="+HP7ph2BbKc20aGI"
Message:
3

Hi all,

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?

Background:

A recent bug report [1] 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
unit tests.

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 [2]
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 became 'flintmax'. 

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.

--Rik

reply via email to

[Prev in Thread] Current Thread [Next in Thread]