|Subject:||Re: Why do we have to deprecate and remove functions?|
|Date:||Fri, 15 Mar 2019 11:59:30 -0700|
On 03/15/2019 09:00 AM, address@hidden wrote:
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?
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|