Re: [Jargp-general] working on unofficial 1.1

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

By the way, the StringTracker class already defines a peek() method 
which seems equivalent to your next(false). I'd prefer the peek() method 
to next(false), since the former seems more intuitive to me.

On the issue of initializing instances of two separate classes from the 
same set of argument values, I'm somewhat torn. This seems like a very 
specialized usage, and I don't know that it's a good idea to extend the 
operation to support it. If you really want to get this functionality, 
I'd think it'd be cleaner to do it by adding an optional target object 
per ParameterSet. ParameterSet already handles delegation to other 
parameter sets anyway, which allows for some parameters to be defined in 
a base class and other added by a subclass; extending it with a separate 
target object would just take this a step further while preserving the 
principle that arguments are processed in sequence and unknown arguments 
result in an error.

I do like the idea of supporting gnu-style "--full-name" parameters, and 
think it should be an easy change to add this support. There've been 
several cases where I've been leaning toward this myself, after defining 
a dozen or so character parameter flags. And I do think the gnu-style 
with two leading hyphens is appropriate, since that way it doesn't 
interfere with the existing character parameter handling.

  - Dennis

Dennis Sosnoski wrote:

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