Re: [Jargp-general] working on unofficial 1.1

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

Added you to the project.

As far as next(false) goes, I really don't like the idea of skipping 
past arguments just so you can process the skipped ones later with a 
separate instance. I agree that the changes to supply a target per 
ParameterSet might be messy... how about allowing one ArgumentProcessor 
to delegate to another one if it doesn't recognize a parameter? That 
way, if you want to split processing between multiple argument lists you 
can set the optional backup ArgumentProcessor in your main one. This 
should also be very easy to implement - just factor out a 
processArgument method in ArgumentProcessor that takes the flag 
character. If it finds the flag character in its parameter set it just 
processes it directly; otherwise it calls the same method on the backup 
ArgumentProcessor. This not only allows for multiple levels of argument 
processing, it also allows you to split flag characters within a single 
"run" between the different ones, something that'd be very ugly otherwise.

You'd also need to make sure the StringTracker instance gets set on all 
the ArgumentProcessor instances for this to work properly, but that's 
just another simple added method (set the StringTracker instance and 
call same method on backup, if defined).

  - Dennis

Matthew Weigel wrote:

> On 8 Jan, 2005, at 9:06 PM, Dennis Sosnoski wrote:
>
>> 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.
>
>
> No, there's a pretty big difference.  With peek(), you don't advance 
> the index, and with next(false), you do.  All three functions - get a 
> value, advance, consume; get a value, advance; and just get a value - 
> are significant.  I agree that the next(false) idiom is a poor one, 
> but I'm not sure what a better approach would be.
>
>> 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.
>
>
> Interesting idea... but I *suspect* that that change will actually 
> require more significant changes to the code, and will constitute a 
> more serious design change for a very specialized usage :-)
>
>> 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.
>
>
> I think that is why GNU did it that way.
>
> By the way, my sourceforge ID is bsdcat.