Why do we have to deprecate and remove functions?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Why do we have to deprecate and remove functions?

Andreas Weber-6
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?

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

-- Andy

Reply | Threaded
Open this post in threaded view
|

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

PhilipNienhuis
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 ...


> 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.

Philip




--
Sent from: http://octave.1599824.n4.nabble.com/Octave-Maintainers-f1638794.html

Reply | Threaded
Open this post in threaded view
|

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

Rik-4
In reply to this post by Andreas Weber-6
On 03/15/2019 09:00 AM, [hidden email] wrote:
Subject:
Re: Why do we have to deprecate and remove functions?
From:
PhilipNienhuis [hidden email]
Date:
03/15/2019 05:27 AM
To:
[hidden email]
List-Post:
[hidden email]
Content-Transfer-Encoding:
7bit
Precedence:
list
MIME-Version:
1.0
References:
[hidden email]
In-Reply-To:
[hidden email]
Message-ID:
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

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

Richard Crozier


On 15/03/2019 18:59, Rik wrote:

> On 03/15/2019 09:00 AM, [hidden email] wrote:
>> Subject:
>> Re: Why do we have to deprecate and remove functions?
>> From:
>> PhilipNienhuis <[hidden email]>
>> Date:
>> 03/15/2019 05:27 AM
>>
>> To:
>> [hidden email]
>>
>> List-Post:
>> <mailto:[hidden email]>
>> Content-Transfer-Encoding:
>> 7bit
>> Precedence:
>> list
>> MIME-Version:
>> 1.0
>> References:
>> <[hidden email]>
>> In-Reply-To:
>> <[hidden email]>
>> Message-ID:
>> <[hidden email]>
>> 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.