Re: [gobo-eiffel-develop] Parsing parameters using the arguments library

[Bernd S. <ber...@in...>]

On Mon, 12 Mar 2007 10:18:29 +0100, Colin Adams  
<col...@ho...> wrote:

> I was not talking about options, but parameters.
> So the minimum would be the minimum number of parameters that can appear  
> on the command line. By default, zero.

Sorry, missunderstood you there. Yes, the problem with parameters is still  
a bit tricker, as you are describing.

> And the maximum woudl default to max INTEGER (a practical proxy for  
> infinity).

Yes, INFINITY would not be a problem, and is the default. I normally do  
not like to work with MAXIMUM_INTEGER.

> So ls can use the defaults.
>
> But many commands would require at least one parameter, and others will  
> require exactly one, or one or two. But it may depend upon the  
> option-set used.

I think it would be enough to have a default min and max, and to override  
these if an ALTERNATIVE_OPTIONS_LIST is selected. Anything more  
complicated would clobber the library.

We have to be aware that there is always some level of command line  
parsing that needs to be done manually anyway. For example, to see if the  
strings passed as parameters are really existing filenames, or at least  
are creatable filenames, cannot be done by the library without a  
significant raise in complexity that I do not want.

> For instance, with gexslt, if the --use-pi option is passed, then  
> exactly one parameter is needed (the source document URI or file name).
> If the --template option is used, then one or two paramters are possible  
> (the transformation URI or file name is mandatory, and the source  
> document is optional).
>
> But if neither option is specified, then both of these parameters are  
> compulsory.

If '--use-pi' and '--template' are ALTERNATIVE_OPTIONS_LISTs, then this  
can be achieved with the suggestion above. And it would keep the  
complexity low.

> It would also be nice to be able to name the individual parameters, for  
> use in the error messages that are generated when the wrong number is  
> passed, but that is a further step, I think.

Also a good idea, if it does not clobber the interface. Anyway, an  
AP_ALTERNATIVE_OPTIONS_LIST already now has an own description string for  
the parameters that is shown in the help page. Perhaps just integrating  
this string into the error text would help.

Bernd