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
Received on Sat Oct 21 14:36:15 2006