general package, inputParser, 4.0.0 release
Carnë Draug <carandraug <at> octave.org>
2015-05-22 16:36:34 GMT
the general package currently implements the inputParser class. The upcoming
Octave release 4.0.0 also implements this class. These implementations are
very similar but different enough that any of its use will require changes
to continue working. Loading the general package will shadow the class but
Octave will not warn about it (seems like it only warns about shadowing
Currently, the best way to distinguish between the two is by checking the
path to the function like so:
if (strfind (which ("inputParser"), [" <at> inputParser" filesep
but we can't really expect users, in special new users that are not aware of
this history, to figure it out.
In addition, a few weeks ago  I expressed my wish of marking the general
package as an unmaintained package. I didn't feel there was much of
opposition to that (but can also be because the email was a fairly long rant
that few read).
This said, I see two possible resolutions:
1. make a new release of the general package without <at> inputParser and
dependent on (octave >= 4.0.0).
2. make a new release of the general package, exactly the same as the
last release, and dependent on (octave < 4.0.0).
Any of the two would prevent <at> inputParser and classdef's inputParser to
co-exist. I prefer the second option for the following reasons:
* users that wrote code for the old version had his code dependent
on general. If it is used on the Octave 4.0.0 it will fail to load
the general package forcing them to become aware of this difference.
* users of old versions of Octave can still use the "latest" version
of the package without having to dig on the old releases.
* since we are "deprecating" the general package, we should make it easier
for the people that will stay on the old versions of Octave, the ones
released when it was "supported".
Unless someone opposes this, I will make a new release of general, still
with <at> inputParser and dependent on (octave < 4.0.0), on Monday.
This would all be avoided if I hadn't implemented an incompatible version
of inputParser on the general package years ago. Hopefully, I have learned