Re: The next step in a table driven client

On Tue, Nov 14, 2000 at 05:53:08PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > > 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.
>
> I think I'm agnostic on the question of hash vs struct...
>
> One nice thing about the struct is that it spells out which things are
> common to all commands -- those are the fields in the struct.

Solvable with svn_client_get_option(longname, cmd_data). When that function
is seen in the code, it is just as obvious as cmd_data->longname.

> On the other hand, you have to keep adding fields. And some things
> are common to only a subset of commands, so what's the threshold for
> inclusion in the struct?...

Right.

> Hmm. Yes, I see what you mean, Greg. I guess I've swung around to
> the hash table p.o.v., then (separate from the filename/dirname hash,
> of course).

The most general mechanism is:

*) a hash table for options
*) an array for the non-option stuff (URLs, files, dirs, tag names, etc)

A struct can make sense to wrap these two pieces up along with "purely
global" items such as "verbose". In other words:

struct cmd_stuff_t {
    apr_hash_t *options;
    apr_array_header_t *args;
    svn_boolean_t verbose;
}

Effectively, the parsing stuff just preprocesses a few flags such as
'verbose' out of the hash table.

That said, I am -0 (not a full -1) on the use of hash vs. struct. I'd much
rather see a hash table, but I'm not coding it (creation or consumption), so
I'm not going to be (too much of) a pest here :-)

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/