[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
general package, inputParser, 4.0.0 release
From: |
Carnë Draug |
Subject: |
general package, inputParser, 4.0.0 release |
Date: |
Fri, 22 May 2015 17:36:34 +0100 |
Hi
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
functions).
Currently, the best way to distinguish between the two is by checking the
path to the function like so:
if (strfind (which ("inputParser"), ["@inputParser" filesep
"inputParser.m"]))
...
else
...
endfif
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 [1] 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 @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 @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 @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
my lesson.
Carnë
[1]
http://octave.1599824.n4.nabble.com/OF-and-packages-devs-please-read-tp4670263p4670295.html
- general package, inputParser, 4.0.0 release,
Carnë Draug <=
- Re: general package, inputParser, 4.0.0 release, Philip Nienhuis, 2015/05/22
- Re: general package, inputParser, 4.0.0 release, Carnë Draug, 2015/05/22
- Re: general package, inputParser, 4.0.0 release, Philip Nienhuis, 2015/05/22
- Re: general package, inputParser, 4.0.0 release, Mike Miller, 2015/05/22
- Re: general package, inputParser, 4.0.0 release, Carnë Draug, 2015/05/22
- Re: general package, inputParser, 4.0.0 release, Mike Miller, 2015/05/23
- Re: general package, inputParser, 4.0.0 release, Julien Bect, 2015/05/23
- Re: general package, inputParser, 4.0.0 release, Carnë Draug, 2015/05/27