Re: [Jargp-general] working on unofficial 1.1

[Dennis S. <dm...@so...>]

Okay, I updated with the minor changes I've made over the last few 
months (mainly just the added StringListDef for repeated string 
parameters, as in your design issue list). I'll add you as a developer 
and you can make your changes. What's your SourceForge user ID?

One thing I've been considering is an active parameter type, which would 
actually call out to user code at the time an argument is being 
processed. This would be useful for loading a set of parameters from an 
XML configuration file, for instance (which could then be overridden by 
later command line parameters).

  - Dennis

Matthew Weigel wrote:

>(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.
>