Re: [Jargp-general] working on unofficial 1.1

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

(again, sorry for my difficulty using an email client and not sending it
to the list for archival)

Dennis Sosnoski said:

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

That isn't the only reason.  The other reason is that in 1.0, JArgP makes
particular assumptions about where non-control arguments show up - they go
at the end.  JArgP just stops processing as soon as it hits something it
doesn't recognize.  If what it doesn't recognize is a control parameter,
it throws an exception; if it isn't, JArgP silently stops.

This behavior is only alluded to once, as far as I can tell, and isn't
completely intuitive - I think that users would expect to be able to at
least precede all control arguments with non-control arguments.  However,
if a user builds their command line like that (to borrow from your article
on reflection, using the command line 'java PlanGen plan.txt -c -f2500
-g2.5 -n "iSue4U - Litigation at Internet Speed"'), then all the control
arguments are lost.

> 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 sounds very reasonable.

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

I'm not sure I follow you here.  Could you illustrate?

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

I'll look into it.
-- 
 Matthew Weigel
 hacker
 un...@id...