apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@galois.collab.net>
Subject Re: RFC on interface change to apr_getopt_long()
Date Tue, 21 Nov 2000 17:17:19 GMT
Okay; +1 on `char short_name' instead of `char *short_names'.  As Greg
points out, for the rare exceptions, one can specify two apr_option_t
structs.

But, in that case, we don't need a short_name equiv field at all -- we
can just use the val field (as the code currently does), right?

So the only real change that would need to happen is that
apr_getopt_long() would no longer take a char *opts string.

How does this sound?

Iteration three,
-Karl

"B. W. Fitzpatrick" <fitz@red-bean.com> writes:
> > On Tue, Nov 21, 2000 at 02:56:52AM -0500, Greg Hudson wrote:
> > > > Keep `val', but add const char *short_equivs, I meant.
> > > 
> > > Okay, so I think the current proposal, with a little renaming to make
> > > everything simple and consistent, is:
> > > 
> > > typedef struct apr_option_t {
> > >     /** long option name, or NULL if none */
> > >     const char *long_name;
> > >     /** short option letters, or NULL if none */
> > >     const char *short_names;
> > 
> > Plural? Is there a case where a long option has *more* than a single short
> > option letter? And even if we can find a case, I'm personally okay with
> > mandating that apr_getopt_long() doesn't support that behavior.
> > 
> > (and if somebody wants to force it, then they can use multiple apr_option_t
> >  records to specify the additional short options)
> > 
> > Hmm. -h -? --help are the same. Fine. One example. I still say that
> > switching that to 'char short_name' is a better API, as it reflects the more
> > common usage scenario (and encourages *single* short options for each long
> > option).
> 
> Hmm. Yes, I think that putting a char* there is unnecessary. -h and -?
> is the *only* example that I can think of where there would be more
> than one.
> 
> -Fitz

Mime
View raw message