Re: The next step in a table driven client
Karl Fogel wrote:
> Greg Stein <firstname.lastname@example.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.
> 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?...
> 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).
> Bruce, any objections? Is there some reason to prefer the struct
> approach, that we're missing?
1. I would have to learn how to use it
2. It won't live very long anyway.
3. I have to finish before you chew up the code on Thursday :-)
4. It has to be trivial to switch the data passing mechanism,
so it doesn't really matter
Received on Sat Oct 21 14:36:14 2006
This is an archived mail posted to the Subversion Dev