Re: [Jargp-general] working on unofficial 1.1

[Matthew W. <un...@id...>]

(whoops, my mailer decided this shouldn't go to the list)

Dennis Sosnoski said:

> What kind of fixes have you made, and what kind of design issues have
you run into?

Fixes:

There were a few cut-and-paste errors in the JavaDoc that I fixed (i.e.,
the ParameterSet and ParameterDef[] constructors to ArgumentProcessor both
refer to a ParameterDef[] argument).
http://sourceforge.net/tracker/index.php?func=detail&aid=1091919&group_id=83036&atid=568105

I added the fix nickjohn requested, making ArgumentProcesser.setValue()
public.  I have not yet tested this, because I haven't created any new
subclasses of ParameterDef outside org.jargp.
http://sourceforge.net/tracker/index.php?func=detail&aid=1027737&group_id=83036&atid=568105

I added the change Rich Gibbs requested, so that it doesn't matter whether
parameters are defined in the current class or a parent class.  If I
understand the issue correctly, I tested this with a subclass of a class
that had parameters defined.
http://sourceforge.net/tracker/index.php?func=detail&aid=838610&group_id=83036&atid=568106

I added the fix I mentioned for a bug in ParameterSet.indexDef(), which
made it not actually work with more than one ParameterDef array.  I tested
this with a subclass of a class that had parameters defined, that added
parameters using a ParameterSet.
http://sourceforge.net/tracker/index.php?func=detail&aid=1089233&group_id=83036&atid=568105

I removed ArgumentProcessor.getIndex() because it is not ever used in the
package, but it is restricted to package visibility.

Design issues:

The main one is that StringTracker implicitly consumes an argument when
you invoke next().  The other is that ArgumentProcessor wants to assume
that precisely one object will consume all control arguments.  From one
design perspective (strictly decoupling the class that gets input from the
command line from all other classes) this is reasonable, but from another
(spreading the convenience of command-line control as necessary) it's not.

The major change I applied was to make StringTracker's consumption of
values explicit; thus you can also explicitly avoid consuming an argument.
 I did this by adding a method, next(boolean isConsumed) and modifying
next() to invoke next(true) so the old behavior is preserved.

I also extended ArgumentProcessor to ignore control arguments it doesn't
understand, by not consuming them.  I accomplished this with additional
logic, and creating a new method, processArgs(String[] args, Object
target, boolean willFinish) where the last argument determines whether
processArgs will assume that it must consume all control arguments or not
(this method's return value is also String[], for the unconsumed
arguments).  I modified processArgs(String[] args, Object target) to call
processArgs(args, target, true) (it still returns the target Object, and
not a String[]).

These design changes allowed me to use ArgumentProcessor in a new way,
initializing instances of two different classes from the same String[] of
arguments.  ArgumentProcessor handles every control argument that applies
to the first class, and returns a String[] of arguments that have not been
consumed; I then pass this argument list, along with a different class and
different ParameterSet, to a second instance of ArgumentProcessor and
initialize a second object.

Issues I haven't yet dealt with:

The assumption that each control argument will be used only once.  I'd
like to support something like "-m foo -m bar" to populate an array with
multiple values.

The assumption that control arguments are of the form '-c'.  I'd like to
suppor strings, either of the form '-word' or '--gnu-style'.

Looking through a diff, I also introduced a new cut-and-paste error in the
JavaDoc, claiming that Object processArgs(String[] args, Object target)
returns a String[] of unprocessed arguments.  I've fixed it and I'll
upload it when I have time.
-- 
 Matthew Weigel
 hacker
 un...@id...