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

[CROZIER Richard]

On 15/03/2019 18:59, Rik wrote:
> 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


Perhaps there could be a 'legacy' or 'deprecated' octave forge package,
where deprecated functions go (depending on their complexity, I guess
anything which depends on the C++ API might have issues, so maybe only
m-files). It could be made clear that these will not be maintained by
the core devs, but maybe community patches will be accepted.

In this case there might also be some merit in putting them in a
+package namespace called 'legacy' or similar. Could even be a nested
namespace with the last version of Octave the function is known to have
worked in like

legacy.6_0_0.strmatch

I guess this could get super complicated when one deprecated function
depends on another though.

Richard
The University of Edinburgh is a charitable body, registered in Scotland, with 
registration number SC005336.