gobo-eiffel-develop

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

[Colin A. <col...@ho...>]

>From: "Bernd Schoeller" <ber...@in...>
>>It seems to me that it would be convenient to be able to set the minimum  
>>and
>>maximum number of parameters expected, which would then reduce the  
>>checking
>>the application had to do.
>>
>>As the number expected might differ according to the option set, then  
>>this
>>should be settable at the option list level (as well as on the parser,  if 
>>it
>>is the same for all (or most) option sets).
>>
>>What do you think?
>
>I had already experimented with such a features, but had not full decided  
>for a satisfactory design. Currently I only differenciate between  
>mandatory or not mandatory.
>
>Giving the maximum number of occurencies seems very reasonable. With  
>minimum: It seems very rare that an option is required 'at least 3 times'.  
>But I might be wrong here. I will probably extend the mandatory mechanism  
>to cover such cases.

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.

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

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.

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.

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.

_________________________________________________________________
Get Hotmail, News, Sport and Entertainment from MSN on your mobile.  
http://www.msn.txt4content.com/

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