I'd much rather see a hash table than One Big Mother Structure that had the
union of all possible flags and options. A hash table seems quite simple.
On Tue, Nov 14, 2000 at 06:55:59PM -0800, Bruce Korb wrote:
>
> My proposal is to *not* do anything significant. :-)
> Instead, it is merely to isolate it so that experimentation
> becomes easy.
Right.
> Then, I will experiment a little bit and
> come up with a proposal. Whatever proposal would be something
> that specified the acceptable/required options to an
> option processing engine that would be driven by that
> something, rather than command name.
Makes complete sense. But my emphasis in this note is to suggest using a
hash table, which is orthogonal to command parsing/driving.
> The resulting state
> would get handed back to the implementation procedures in
> any of a myriad of ways.
>
> For the time being, this is far and away the most trivial
> to implement and use for an experimental framework:
>
> typedef struct svn_cl__opt_state_t {
> svn_string_t *xml_file;
> svn_string_t *target;
> svn_string_t *ancestor_path;
> svn_boolean_t force;
> svn_cl__command cmd;
> const char *use_text;
> } svn_cl__opt_state_t;
>
> a pointer to this struct gets added to the command descriptor.
> The option processing routine takes this ptr as an argument, instead
> of the addresses of each of the fields. It is trivial and gets me
> closer to where I want to go, even if the destination still has haze.
-0 on this approach.
The hash table has longer term growth and seems just as simple.
>...
> > Greg Stein <gstein@lyra.org> writes:
> > > I'd suggest passing the options information to the command in
> > > a hash table. The command can simply do something like
> > > apr_hash_get(hash, "v") to get the information.
>
> > > Throw in a bit of default value handling, long/short option
> > > handling, and you're set.
>
> Yeah, easy. It's only software. But too ambitious for tonight.
Yes, those are certainly second round additions. The initial question seemed
to focus on how to pass option/command data between the parser and the
command functions.
> > > The second part would be determining what is possible for a given command
> > > and providing errors/warnings for options that don't match up properly.
>
> Right now, I'll do that just with the command code enumeration.
> The real implementation will do something better.
Right-o.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:14 2006