octave-maintainers
[Top][All Lists]
Advanced

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

Re: legacy functions


From: Rik
Subject: Re: legacy functions
Date: Fri, 3 Aug 2018 21:33:12 -0700

On 08/03/2018 07:12 PM, address@hidden wrote:
Subject:
Re: Legacy functions
From:
PhilipNienhuis <address@hidden>
Date:
08/03/2018 12:19 PM
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:
4

Rik-4 wrote
Now that we have a new category of functions in the scripts
directory--functions which Matlab recommends against, but hasn't actually
eliminated--what other functions should we put there?

These look like possibilities: findstr, flipdim, strmatch, strread.
... textread, ....

To be complete we'd have to check quite a few functions and also change
docstrings; is it really worth developer time & -priority?

I was viewing it from the other perspective.  It's really easy to put a single line, "This is not a recommended function." at the top of the docstring, move the function to the legacy directory, and then stop worrying about making the function Matlab compatible since neither Octave or Matlab wants programmers to use the function.

Also noting that all this apparently has been triggered by a user that wants
to run Matlab code that has gone unchanged for ~13 years.  No opinion on
that [*], but rather at consequences for our priorities.
Matlab compatibility is one of the biggest foundations of Octave's success
but I sometimes wonder how far the octave project should go in exactly
mimicking Matlab behavior, in this case informing about obsoleteness. 
What is the compatibility target anyway: the very newest Matlab release, or
do we lag behind a few releases? (we already do w.r.t. several things: v7.3
mat files & classdef, new string class, table class, object-based graphics.)
No clear answer on that.  I think we still aim for "mostly" compatible.  If someone really, really has an itch for a particular Matlab quirk they can always pay to have that implemented, and maybe just for them rather than making it in to Octave core.

--Rik

reply via email to

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