Re: Why do we have to deprecate and remove functions?

[Rik]

On 03/15/2019 09:00 AM, address@hidden wrote:

Subject:

Re: Why do we have to deprecate and remove functions?

From:

PhilipNienhuis <address@hidden>

Date:

03/15/2019 05:27 AM

To:

address@hidden

List-Post:

<mailto:address@hidden>

Content-Transfer-Encoding:

7bit

Precedence:

list

MIME-Version:

1.0

References:

<address@hidden>

In-Reply-To:

<address@hidden>

Message-ID:

<address@hidden>

Content-Type:

text/plain; charset=us-ascii

Message:

1

Andreas Weber-6 wrote

Dear all,

what is the reason to deprecate functions? Is it just to be as MATLAB 
compatible as possible or to keep the codebase as small as possible?

Reducing maintenance burden, obviously I'd say.
While strmatch etc. may still build and work fine now, perhaps some change
in the future could unintendedly cripple them and at that moment the
question will arise what to do then. It seems better to decide now about
continued support in the future.
But, read on ... 

Maintenance burden is a big one.  But there is also a namespace issue.  Poor early architecting by Matlab has meant that there are a lot of functions in the global namespace.  The Mathworks has added workarounds, such as private/ directories and +packages to reduce the clutter, but try __list_functions__ () in Octave today and I still get 945 visible functions.  Each slot is a potential namespace clash with a user function or a function from a package.

Also, sometimes things just got named badly.  The function which returns the largest integer capable of being represented in a floating point number began its life as "bitmax".  That was not a great choice.  The "bit" prefix makes one think of the bit-oriented functions like "bitset", "bitcmp".  This was eventually renamed to "flintmax" which is analogous to the "intmax" function, but for floating point ("fl") numbers.  We could have kept bitmax around, but why bother since there is identical functionality in flintmax?

I ask because I have to maintain code which has to run on Octave >= 
3.8.2 up to current versions which is often hard because functions were 
removed which have worked without problems for years.

One example for a deprecated function is "strmatch". Currently I use it 
this way:

strmatch ("foo", {"abcd", "foobar", "foox"})
ans =

    2   3

After 5.1.0 I think I have to use:

find (strncmp ("foo", {"abcd", "foobar", "foox"}, numel("foo")))
ans =

    2   3

AFAIK strmatch is still working in 5.1.0, it's in scripts/legacy/ these
days. It's still even in 6.0.0.

Otherwise I do sympathize with you POV.
In my crossbuilds I removed the IMO somewhat obsolete warning about
obsoleteness of strmatch. Matlab until r2019a doesn't warn similarly, in the
Matlab docs it only says that strmatch is not recommended but no sign of
future removal. Furthermore Matlab has introduced functions startsWith() and
validatestring().

I think that once strmatch is finally dropped I'll create a wrapper called
strmatch for myself around strncmp() as above; at work strmatch pervades the
local Matlab function library about everywhere.

strmatch isn't going anywhere, anytime soon.  It it is well entrenched in a lot of old code.  However, if you can base your new code on strcmp/strncmp that will be better, and potentially faster as strmatch is an m-file versus C++.

Also, if you are going to use legacy functions a lot, and aren't going to update code to new functions, you can shut off the particular warning with

warning ("off", "Octave:legacy-function");

This might be appropriate for the project specific .octaverc in the directory that contains legacy code.  I would be wary about applying it globally in your ~/.octaverc file.

--Rik